Final Fantasy Hacktics

I might have neglected to mention this, but I'm running through the issue list up on Tethical's github page. The rain effect and the scrollable abilities list are on that issue list. This is code for a scrollable abilities list: Test Menu











It's pretty flexible for what it is, I think. However, I haven't put it into a Python class yet. I don't know what there is to really critique about it, but, if anybody spots something, feel free to point it out.

Besides the incompleteness of the code, what's obviously lacking as of now are graphics to replace the text I used as testing arrows. However, Panda3d makes that easy to change, so don't worry about that.

Dear lirmont, thank you for your code.
I just tested it, and it is flexible.
But our current codebase uses the DirectGUI lib from Panda, and images to let the users theme their GUI.
I understand that the way you choose is better on some points.
But improving the current code base would ask for less work than recoding the whole GUI.py your way.
This evening, I will commit an exemple of how I think it should be done.
Sorry for not having been more precise in the github page for this feature request.

[EDIT] I just pushed the patch. You can run test_menu.py

Here is a version of my previous code that exists within the DirectGUI example you provided: Test Menu



Basically, all the code I had written to draw the menu geometry now delivers a nodePath to the DirectFrame item that used to be the screenshot of the empty menu. The point is, you can now use the "MenuNodeDrawer" class to whip up a menu background without having to screenshot something that already exists in FFT. It all behaves within the bounds of the concerns you expressed in the previous post (input, effects, etc). Now, don't get me wrong, there's still more work to do on it, but I think this is at least a step in the right direction (versus copy/pasting from FFT in a direct manner). Also, I don't know how much you tested my code before, but it has options NOT to do the header and footer to the table, so it could also be used any place FFT menu-esque things are drawn.

You are Invincible, keep up lirmont

Ok I understand now. You want to build a lib to draw the backgrounds of the GUI.

This is a very good idea.

I still think that images are better than code for themers. What about spliting the FFT screenshot frame in 9 images (4 corners, 4 sides, and the bg) and rewrite the node drawer using these ? We could have alternate top and bottom images. Tell me.

For me the most difficult thing to handle was the other part: the text, cursor, ruler, and their behaviour. Now I understand how to code it. This can be part of another lib.

Your node drawer is going to be very usefull.

Yes, using images instead would allow for themes, but the current filesystem isn't laid out to support having a place to separate themes into folders. Going by the rest of the filesystem, I assume you'll want them in sub-folders like:

/client/fft/textures/gui/default
/client/fft/textures/gui/sky-blue
/client/fft/textures/gui/gray
...
/client/fft/textures/gui/etc

When I convert the code to using only images for the menu drawing, I'll just keep a variable in the constructor that accepts a directory name until this idea makes it into the Config class. Thanks.

Yes if you want we can support multiple GUI themes per game.
In fact, I thought that the theme system was like this :
/client/fft/
/client/lijj/
/client/etc/
because textures, maps, sounds and gameplay should match.

But I admit that GUI themes are a special case, and that multi theme support will sooner or later be in the feature list, so let's do this.

Understood. I know FFT doesn't do it, but almost every other FF game has the option of multiple themes per game (as opposed to a single theme per game like FFT). Anyway, I've gone ahead and treated it like a special case for the code. To reuse them between games would be a simple copy-paste of which folders you want beneath the "gui" folder.

Here's the result of replacing the line-drawing with only images:

Original:


A rounded-corners CSS design off the web:


The only thing that changed between the two is the item height and the path from which the 9 images per drawing area (heading, body, end-cap) were loaded.

Menu: Test Menu

Very clean code!

On the first screenshot, the resolution of the frame borders is 2x too high. This is how the frame should look if we where at 256x240, but here we have 512x480. Here are some screenshots of how the frame should look at different window sizes.

You can uncomment GUI.Test('test_menu') to display the screenshot behind your frame, in test_menu.py. For now the GUI has been pixel perfect and I would like to keep that please.

Believe it or not, there's actually probably already a setting for that. I chose not to put them it in the constructor, but you can find the two variables "screenCanvasWidth" and "screenCanvasHeight" at the top of the list on MenuNodeDrawer's class variable list. Set them to your desired width and height (256 and 240, respectively), lower the item height in your GUI class for the MenuNodeDrawer object (~17 should do), and you probably will have the right resolution. If you have the right resolution and it still looks off, then that's my fault for cutting the image up wrong, so the fix would be to edit the wrong images (versus more programming). Also, I think values for the two variables I mentioned probably belong in the Config class along with the GUI theme directory selector, but hard-coding it for now certainly has no immediate downsides.

I pushed a simplified version of your node drawer (60 lines) able to display those types of windows: simple, shadowed, list with headers, flat, and rounded dialog. Now I have to rewrite some parts of GUI.py to use it.
The scrollable list class takes care of displaying the text and the ruler, the ruler is auto disabled if not needed.

Looks like a pretty big success to me. Point me in the right direction Panda3d-wise, and I'll work on getting a bitmap font available for the heading text.

Unfortunately, the heading text is not made of fonts in FFT. The words are unique bitmap

But there is a lot of FFT fonts to port, (and of course we can try to emulate the heading with fonts, but I would not prefer for now).

So let me start a new topic about making bitmap fonts with Panda. This is a very long process with a lot of steps, and since I updated my Panda on Arch Linux, I'm no more able to export fonts, but you may be able to do it on windows, or find out what are the new options to use for egg_mkfont to fix this problem.

[EDIT] I posted a tutorial about the fonts. And I added a new argument to display an image title attached to the frame. I'm currently porting all the old GUI classes to the NodeDrawer or the ScrollableList. Take a look at this patch https://github.com/Kivutar/tethical/commit/fb86afc9eadee39c3be238e309d0c44b2f0b33ad, pure bliss  Without you this would not have been possible.

Yeah, I agree after giving it a shot. It's not worth the effort, the result is bad, and bitmap fonts/EGG format is too specialized to handle the kind of kerning required. I'm disappointed that any customization will have to depend on the pre-existence of something to customize (that is, being limited to replacing existing header images AND NOT being able to generate them on demand). I'll post this bitmap font anyway as evidence of my attempt, but it turned out to be disappointing: fft-white (this is not the small-caps variant required for menu headings).

Well this is not so bad. The biggest thing is the resolution. Do you know why they don't have the right size? Another thing is the digits alignment on Y. I can't tell about the spacing, because of the wrong resolution. But for a first attempt, it is a nice result.

What arguments did you use for egg-mkfont?

This is coming along nicely- keep it up! I hope we can start seeing more of the original maps and stuff soon!

@Eternal: Thanks! Other stuff is more important than that at the moment, I think. Getting some of the behind the scenes infrastructure in (like the menus in the previous posts) will probably result in a more playable game. There is still a HUGE step I know Kivutar has hinted at, which is data storage/persistence. That is, that might take the form of a database or file storage, but it's something that has to be designed and implemented before you can -see- all the work come together.

@Kivtuar: Oh, it's because the scale was wrong. The scale in the test file was for 12px whereas these are 9px. My mistake.

@Eternal: adding more official maps is easy, I could push the map exporter in the same folder as the sprite exporter. I did not do that for now because the map exporter is still in map2gl, wich is not our code. Maybe pushing it anyway would ease the process if someone want to clean it and remove the map2gl specific code.
But lirmont is right, we are working on very important code refactoring at the moment.
This afternoon, I ported the help messages to the new node drawer. The next step will be the confirmation messages. There is less and less screenshots used by the engine. This is the right way if we want real theme support.

@lirmont: If I recall correctly, setting a 12px in the font file would allow us to keep the same scale for the fonts (12px/screen height). But I'm not sure that it is such a good idea to keep all those false ppu in the project. What do you think?

Concerning the database, I'll start a topic tomorrow. FFH community can help a lot on this point, because they know very well the original game. We'll have to find the right tune between FFT compliance and genericity as we plan to be a game agnostic engine.

Yeah, the only important thing turned out to be making a font in fontforge with 12 for "Pixel Sizes" in "Element"->"Bitmap Strikes Available". 12 ppu, I believe, is unimportant to pass so long as the original font you make in fontforge has the 12 for pixel sizes. Anyway, this is the same font as before in 12px (meaning, it works with the scale correctly): fft-white-12 (again, not the small-cap variant used in the actual game for headings).

Very close to perfection. These are the last 2 errors my eyes can detect without comparing with a screenshot:
- the digit vertical alignment: the base of the zero must be align to the base of the point, all your digits are two pixels too high.
- letter spacing.

You can solve these two issues with the same solution: in Fontforge character editor, you are allowed to draw some pixels out of the bounding box defined by the theorical width and height of your character. The opposite is also possible: lower the "case" of your character 1px on the left to create a negative margin.

Yes, making font with these tools is a pain in the ass...