øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;u=14;area=showposts;start=45e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index442f.htmldelayedslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=14e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/index442f.html.zxƼg^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ0P.YØOKtext/htmlISO-8859-1gzip@øÕYØÿÿÿÿÿÿÿÿÑHTue, 10 Mar 2020 16:30:22 GMT0ó°° ®0®P®€§²ð®Ƽg^ÿÿÿÿÿÿÿÿÌ YØ Show Posts - Pinkpuff

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Pinkpuff

46
Is it sad that I don't actually know? LOL

Sorry everyone that I haven't really touched this project in ages. I feel like I really should finish the overworld editor at the very least (and ideally fix all the known bugs) before abandoning it completely but I'm a bit stuck with regard to reading the graphic tiles (they're stored differently from the way the "inner" map tiles are stored, of course, because that would have made sense) and the longer I leave it the more I forget about my own code and have to relearn.

In the meantime I've been poking around with NES homebrew coding and have made some progress. I can display backgrounds, read controller inputs, and dynamically update background tiles based on said inputs without flickering or graphical artifacts. It may not sound like a lot, but it took a lot to get even that far. I've also been working on creating a tabletop game using the same fundamental idea and mechanics I used for my "Final Fantasy Card Game" (http://timecave.net/games/ffcg/) but without all the SE copyrighted content, the idea being maybe I can release (and/or sell?) something similar to a wider audience.

I also find I've been devoting less time to my projects in general lately due to a combination of working, slacking off, and playing games. I've been particularly absorbed in Brave New World. I've never been a fan of FF6 in its original form. It certainly isn't the worst FF by any stretch of the imagination, but for me it was sort of the beginning of the end for Final Fantasy. Ironically, that kind of makes the "destruction of the world" scene (and general motif) particularly poetic. Anyway, Brave New World basically fixes all my beefs with the game as it was designed originally and makes it into the game I had somewhat imagined and/or expected it would be. Dare I say, the game we should have gotten.

Anyway sorry for the meandering rant. Point is, progress is slow but I'm still kicking ^_^

47
THANK YOU for the info on unused/redundant enemy AI. I was just about to start searching for this.
Yeah, Grimoire is my hero. His research has saved me SO MUCH TIME while working on my project.
Well, pinkpuff, too...
Both of them are my hero.

We've all come through for each other.

48
The size flags could be something similar to the size byte in FF4. Do monsters of the same size graphic have the same settings for their size flags?

Shadow might have something to do with whether the monster literally casts a shadow, i.e. floating monsters. Those exsted in FF5, right? Maybe I'm imagining things.

Compress... no idea. Maybe some part of the process involves some kind of data compression?

This is all pure speculation on my part. I enjoy playing FF5 now and then but I have never looked inside the guts of the rom.

49
Without having looked at the rom (or really anything about FF5's inner workings whatsoever), just the text you posted:

14B180: monster images
1B: compression flags
15B: image address
1B: size
1B: shadow flags
4B: unused
2B: color ID high byte
1B: color ID low byte
1B: form ID

Not sure how useful any of that is, but that's all I got.

50
Thank you so much for replying and explaining this! I think I get the gist of it, but I'm not 100% sure on the details, so I'd like to run through some "real" data as an example to make sure I get it:

I'm using a headered rom here, so these will be headered addresses:

So the "pixel" data should begin at E8200, correct? For me, it appears the first 32 bytes are all 00s. So if each byte encodes two pixels, then every two rows of 16 byes are essentially a tile. So the first tile is just a grid of all 00s, so let's ignore that one and move to the next tile, the one starting at E8220. We have:

Code: [Select]
34 34 34 34
43 44 43 43
34 34 44 44
43 43 43 43
34 34 34 44
43 43 43 34
34 34 34 44
44 43 43 43

So each nibble or "half-byte" is a pixel, so we can more or less just separate it out:

Code: [Select]
3 4 3 4 3 4 3 4
4 3 4 4 4 3 4 3
3 4 3 4 4 4 4 4
4 3 4 3 4 3 4 3
3 4 3 4 3 4 4 4
4 3 4 3 4 3 3 4
3 4 3 4 3 4 4 4
4 4 4 3 4 3 4 3

Next, there's a byte that gets added (or "or-ed"?) to each of these pixels? And it comes from A0800? This is the second tile, so it would use the second byte, so 10? So adding 0x10 to all of these would produce

Code: [Select]
13 14 13 14 13 14 13 14
14 13 14 14 14 13 14 13
13 14 13 14 14 14 14 14
14 13 14 13 14 13 14 13
13 14 13 14 13 14 14 14
14 13 14 13 14 13 13 14
13 14 13 14 13 14 14 14
14 14 14 13 14 13 14 13

There seem to be only two colors used in this particular instance, so we can look those up. The palette data is in a table at A0B00, correct? And looking at my code for palette reading, it should be two bytes per color. So color 0x13 would be at A0B26-7, so 52 2B, which would yield (if I did my math right):

12 Red
1A Green
0A Blue

That turns out to be sort of a lime green color. Then there's color 0x14, which would be the next two bytes, 11 23, so:

11 Red
18 Green
08 Blue

That's a similar but more medium green color. So this is I guess part of some kind of grass tile.

Anyway, is my process correct?

51
These are unheadered offsets.
0A0000: Overworld tile assembly data
0A0200: Underworld tile assembly data
0A0400: Lunar tile assembly data

0A0600: Palette assignment data (overworld)
0A0700: Palette assignment data (underworld)
0A0800: Palette assignment data (lunar)

0A0900: Palette Data (Overworld)
0A0980: Palette Data (Underworld)
0A0A00: Palette Data (Lunar)


0E8000: Overworld subtile graphics
0EA000: Underworld subtile graphics
0EC000: Lunar subtile graphics
(4bpp linear reversed, combined with palette assignment data to make 8bpp subtiles)

I'm trying to get FF4kster to read these graphics and I'm having trouble. What does this part mean:

(4bpp linear reversed, combined with palette assignment data to make 8bpp subtiles)

Is this read differently from the graphics for, say, the ship/airship tileset?

Also the "Tile assembly data", does that work the same way as it does for "inner" tilesets?

52
Doesn't the slash key bring up numbers for those?

53
Started my own playthrough of this:

https://www.youtube.com/watch?v=-DwQwtT7dlc

54
Gaming Discussion / Re: Movies of playthrus
« on: February 19, 2016, 07:16:01 PM »
Just gonna leave this here:

https://www.youtube.com/watch?v=Te5ZKklpFR4

55
I've never been able to get anything other than the regular screen modes (1 - 13) to work in FB under DOS.

56
It has more to do with the way FreeBASIC's palette commands work in higher color depth modes. In the DOS modes it wants you to say something like "COLOR 12" meaning "use whatever color is in palette index 12"; in the graphics modes, you wouldn't worry about indexes and just tell it the RGB values

57
Despite what it may look like, it's actually a graphics mode and uses a type of palette assignment that DOS screen modes of that resolution aren't compatible with. To get full color depth in DOS in FreeBASIC, it would require changing the resolution and thus the entire interface.

58
Turns out there is a major hinderance to a DOS port of FF4kster; namely, the screen mode is not supported and changing it would involve a major rework of how the graphics are handled.

Sorry, chillyfeez  :isuck:


59
Sweet, I'll see what I can do this week.

60
Unless FreeBASIC now has an Android target, which seems unlikely I'm afraid, it would be extremely difficult. I also can only imagine the horror of trying to navigate FF4kster's keyboard interface with the Android pop up keyboard. Bizarrely, what might actually be easier is if there is an MS-DOS emulator for Android, I should be able to compile FF4kster for DOS without much difficulty.