• Welcome to Final Fantasy Hacktics. Please login or sign up.
 
March 28, 2024, 11:18:58 am

News:

Please use .png instead of .bmp when uploading unfinished sprites to the forum!


Progress Update (01-07-2013)

Started by lirmont, January 07, 2013, 07:07:03 pm

lirmont

January 07, 2013, 07:07:03 pm Last Edit: January 07, 2013, 07:17:45 pm by lirmont
Damage Display



Note: Works with any Panda3d font; in, out, and final animation are all controllable by way of code.

Video: tethical-damage.zip


Bonus Money Spinner



Note: Works with any Panda3d font.

Video: tethical-bonus-money.zip


Client-Side Battle Viewer



The LED on the right-hand card is a black dot, , but it gets run through a color dodge Cg shader I wrote to make it pulse with the team's color. You can also look back through older threads to see how the boxes and the bars are composed of individual pieces.

Video: tethical-battle-hud.zip


Battle-Ready Sprites



Saturation at 300 degrees gets rewritten by a Cg shader I wrote to be replaced by the appropriate team color (specifically, the pink color gets turned into a grayscale color then multiplied by the team color in real-time on your graphics card). This applies to anywhere the sprite resource is used. For instance, if you look in the battle screenshot, you can see that the portrait proxy object is colored to match the on-map sprite resource. In other words, since both characters in the mock battle are human male squires, there is only one sprite loaded for the whole battle; the shader and various Python classes I've written take care of coloring and animation.


Code-Related

Exp award, Jp award, character level up, and job level up are also implemented using vanilla formulas; you can see EXP and level in one of the videos; those are database-driven values served by the server application displayed by the client-side battle viewer. The battle viewer in the video is spectating a battle, but can move the cursor and camera around; it updates when the battle loop advances and the server pushes actions out to clients. One of the characters (the one with all that damage) is also played by a wait-only AI module. You can see the defaults I wrote for those two characters here (which one has grown from and one has not): character data.

Lijj

I find your automatic paletting system interesting (lol the hot pink sprite). The water in motion is good as well; maybe some twinkling could help but the flowing motion and rate are awesome.. I'm glad to see this going on.
The sound effect for the spinning numbers is a little odd and low bit sounding, but cool in a way.
The only thing that I don't like aesthetically on the HUD is the  zodiac/ sex / race / orientation info thingy looks so different from everything else and it's in a different rez.
I do like how the light's will match team colors though!
  • Modding version: PSX

Choto

Lijj looks good in hot pink lol.

Look awesome man!

Ramza1

Just want to say how much I support the Idea of this project and I can't wait to see it fully finished. While I know virtually nothing If I can help please let me know
What is this...signature that you speak of?

lirmont

January 08, 2013, 11:17:17 pm #4 Last Edit: January 09, 2013, 05:03:05 am by lirmont
Thanks for staying interested in this project.

Also, GLSL shaders I ported to Nvidia's Cg shader language. Maybe you've used them in ePSXe before.

Cartoon Shader Class C, Shader #3, written by guest(r)






Bump Map Shader, written by SimoneT






Choto

Definitely still interested, hope all has been well with you man.

Pretzilstix

Oh my, how fantastic. Looks even more beautiful with the shader. I am really in full support of this project. If you need any music for the game, let me know. It's a long shot, but I might be able to get a friend of mine to let me record his orchestra. Depending on what kind of feel you're going for, of course.

Mobius

May 18, 2013, 02:26:53 am #7 Last Edit: May 18, 2013, 02:38:24 am by Mobius
Allright, I got some pointers.

From an artist point of view, the good thing about having multiple palletes is that you get to choose exactly which colors the sprite will have, instead of having them generated in set hues and lightscales.. It honestly makes them look flat and unnatural, as I see here.

I was wondering if having a sheet for each color take too much size?


I also see an issue with the sprite resolution being in x2 when compared to the more detailed map textures, which don't fit at all here. So either the sprites go high-res in x2 size or the maps go for less resolution, and quite easy so, as the tiles from FFT can be used for this.  ;)

I could go on and criticize, but I'll assume they're just placeholders. And if so, bigger sprites to go with the high-res tiles would be great for showing this as an engine for people to use. Not so much for recreating FFT.
Now everyone sit down, relax and have a good damned cup of tea.
Then go out into the forest and see the stars.

Then come back and realize it's pointless to be so worked up over what's meant to be our hobby.
That should be my motto here, holy s

lirmont

Quote from: Mobius on May 18, 2013, 02:26:53 amFrom an artist point of view, the good thing about having multiple palletes is that you get to choose exactly which colors the sprite will have, instead of having them generated in set hues and lightscales.. It honestly makes them look flat and unnatural, as I see here.

I was wondering if having a sheet for each color take too much size?


Yes, it can still be done, you just leave out any pink areas. You'd need to change the reference implementation's code to look for a specific color name in the file listing of available sprites so that something like "human_superknight_male_orange.fft-type1.bmp" gets loaded instead of "human_superknight_male.fft-type1.bmp".

File size isn't the issue. Sprites are small; that's their benefit. The issue is dealing with the need to handle arbitrary team colors. If you only want to allow a small number of different team colors ever, it's doable to provide specific palettes. You could even add more as you get time. However, if you don't have a generic fallback approach (the hot pink plan), then what will the engine show, and will it confuse the user?

I am aware that the colors don't currently step perceptually the way that pixel art does. However, that's just because the shader I wrote isn't that sophisticated yet. It's completely possible to programmatically figure out appropriate color steps for a given color (re: the team color). Check out the documentation of the color control I wrote into the sprite animation tool (the color control is accessible by setting the raw overlay color or through the paint mode while you're editing a selected composite frame). You could, for instance, accurately guess that you only want a given X% of color change and scale the black and white scale automatically and appropriately per team color. Again, the shader I wrote to do the color replacement is simple and has room to be improved on for an actual production-level game (as opposed to being unusable).

Quote from: Mobius on May 18, 2013, 02:26:53 amI also see an issue with the sprite resolution being in x2 when compared to the more detailed map textures, which don't fit at all here. So either the sprites go high-res in x2 size or the maps go for less resolution, and quite easy so, as the tiles from FFT can be used for this.  ;)


Due to how 3D graphics are stored, you can choose how detailed (or not detailed) each tile is. Those tiles are 40x40. FFT's are 20x20.