øAslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&topic=2365.msg27733e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexb21f-5.htmlslickproductions.org/forum/index.php?PHPSESSID=5f0fck550j2m4m2fpbtkj2vkm1&action=profile;area=showposts;u=383e:/My Web Sites/Slick Productions - FFIV Message Board/slickproductions.org/forum/indexb21f-5.html.zx‰¿h^ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÈ ,/+*OKtext/htmlISO-8859-1gzip0|Ö+*ÿÿÿÿÿÿÿÿWed, 11 Mar 2020 10:54:25 GMT0ó°° ®0®P®€§²ð®ˆ¿h^ÿÿÿÿÿÿÿÿ´4+* FF1:DoS Projects

Author Topic: FF1:DoS Projects  (Read 1237 times)

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #15 on: August 08, 2017, 12:18:45 PM »
After another while (and a hospital visit), I'm back. I took a break from moving forward with the hack to rip every tileset used by the game. One thing led to another and now I can edit maps semi-conveniently, using Tiled Map Editor.

It's not a perfect system, of course. Most tilesets have two sets of tiles used depending on whether you're inside a room or not, and a tile's graphics, palette and properties are all tied to its ID, which doesn't mesh well with how Tiled works. At some point I'll want to code a dedicated map editing tool for FF1-DoS, but for the moment Tiled works pretty well:


And, yes, that is a gigantic map. I got a little carried away, so the encounter rate is going to be cut to compensate. In fact I've reduced the frequency of random encounters in general; there are simply too many in vanilla Dawn of Souls, especially compared to the NES original's more restrained rates.

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #16 on: August 13, 2017, 08:39:41 PM »
Continuing on, I've recently coded and implemented a big change to the way equipment works:
  • Equipment cannot be changed during battle
  • Equipment that casts a spell can only be used in this way while equipped
  • Spells cast from enchanted equipment (or items!) do not benefit from the user's Intelligence
This has a big impact on the way enchanted equipment is used - instead of anybody being able to use anything anytime, you have to be able to equip the piece and give up the appropriate equipment slot for it, so making use of a Healing Helm means a Knight or Ninja is going to miss out on a Ribbon. Preventing midbattle equipment swaps goes hand in hand with this design and eliminates the temptation to micromanage your weapons and armor each turn for the precisely optimal setup at that moment. Instead, equipment decisions must be committed to before battle begins, and using enchanted equipment becomes a more serious choice. In lieu of a more extreme reworking of how the inventory works, I like this system.

And since I still feel like writing, some thoughts on stat design - namely, the primary statistics Strength, Stamina, Agility, Intelligence and Luck. My philosophy with FF1 is that each stat should serve either one specific purpose or a few smaller ones; characters already have their levels classes, equipment and spell choices to set each other apart and define their power levels. With that in mind, here's how I'm thinking the primary stats should operate:

Strength
Influences physical attack power:
  • Unarmed Master: ATK = STR + LVL/2
  • Unarmed other classes: ATK = STR/2 + LVL/2
  • Armed characters: Adds STR/2 to Attack
Strength does one thing and one thing only, which is just fine by me. It might be nice if Strength points above a given cutoff had a greater effect on your Attack (eg if you have more than 50 Strength, you add [STR-25] to Attack). A more radical alternative would be to make Strength influence a character's number of strikes instead of attack power, but I'm fine with the system I have.

Stamina
Adds STA/4 to maximum HP on level-up
Determines Master defense, Monk unarmored defense

Also pretty simple; the way it works for the Master is that his Defense is equal to STA/2, regardless of any equipped armor - he just ignores their defense values. Still, I don't like how Stamina only has a marginal, out-of-combat use for other classes. One idea I have to make Stamina more valuable generally is to allow it to mitigate a character's chance of being inflicted with a status ailment from a monster's physical attack, where:
Code: [Select]
Current: M = RES
Proposed: M = STA + RES/4
This makes the Master uniquely resistant to status attacks while still leaving him vulnerable to the effects of spells.

Agility
Adds to Evade
Leader's Agility slightly influences chance of an Ambush/Normal/Preemptive Strike random battle
Influences turn order:
Code: [Select]
Priority = random number from (AGL/4..AGL+10); units with higher priority go earlier in a turn
This turn order formula is, btw, an edit of the vanilla formula of rand(AGL..AGL+50).

Vanilla Dawn of Souls makes Agility do even more things than this, but I'm still wondering if Agility is involved in too many formulas; I might like to make Evade based solely on your class (possibly with a level component) and equipment weight. What do you all think?

Intelligence
Increases power of damage and healing spells (rough formula is Damage = X + (INT*Y)/4 before defensive modifiers)
Increases accuracy of indirect spells like Slow and Hold

I'm continually indecisive over whether to make INT continue to directly affect spell damage, or to use an NES-like formula where damaging spells have an accuracy roll and deal double damage on a 'hit'. Otherwise Intelligence is right where I like it.

Luck
Influences success rate of Flee command
Adds a little bonus damage to damage spells
Target's Luck influences amount of HP restored by healing magic
Leader's Luck slightly influences chance of an Ambush/Normal/Preemptive Strike random battle
Cannot be modified by equipment

Luck does a lot of little things, but apart from maybe removing its bonus to attack spell damage I think that's acceptable. The main thing is the chance to run away; everything else is just a bonus. Dawn of Souls normally makes your chance to run based on Agility, Intelligence and Luck, but I think it's much more sensible to base it just on Luck; Agility already helps you out by letting a character try running earlier on in a round anyway.

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #17 on: August 14, 2017, 03:20:52 AM »
It's not a perfect system, of course. Most tilesets have two sets of tiles used depending on whether you're inside a room or not, and a tile's graphics, palette and properties are all tied to its ID, which doesn't mesh well with how Tiled works. At some point I'll want to code a dedicated map editing tool for
Making a tile editor is enormous task. However if you think a tool that can automate (help with heavy lifting) some/all task of transferring Tiled work to your ROM could help you, I'm willing to code it for you :D

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #18 on: August 14, 2017, 12:39:40 PM »
That's very generous of you! As it happens though, most of the work goes into setting up the map feautres and tile properties as well as just drawing the tiles; converting the tile data from .tmx to binary format takes only a couple of minutes, whereas mapping for the Waterfall was an hourslong process. Still, thank you for the offer.

If I can ever find the time to dedicate to such a project, an all-in-one map/tile property/map features editor for FF1-DoS like FFHackster's map editor would be ideal for this game; at some point I want to make a general-use editor for Dawn of Souls (probably in Python or Java), but that's a long-term prospect; programming a binary file editor like that isn't something I've ever done before.

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #19 on: August 15, 2017, 01:59:27 AM »
That's very generous of you! As it happens though, most of the work goes into setting up the map feautres and tile properties as well as just drawing the tiles; converting the tile data from .tmx to binary format takes only a couple of minutes, whereas mapping for the Waterfall was an hourslong process. Still, thank you for the offer.
You are welcome. It is still there, so if you change your mind just PM.

BTW you cough my curiosity: sure preparing a map is time consuming task, but somehow I always assumed that when all is done, injecting the work in a ROM is a task on its own and I expect boring staff like converting to binary of tiles, palettes and the map-data itself,... pretty much things that may not be hard to do, just tedious and easy to make a mistake. On top of that most GBA titles store tiles in compressed format (including FF5a), so that may require an extra step. So if you do it manually - does it mean that Tiled can convert its data to binary that can easily be used in the ROM?

Sorry I just poured out my thoughts. I guess the right question is: what data you get from Tiled and what data you need for FF1a (just in general no need for details)?

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #20 on: August 15, 2017, 09:52:33 AM »
Sorry I just poured out my thoughts. I guess the right question is: what data you get from Tiled and what data you need for FF1a (just in general no need for details)?
Having drawn the map in Tiled, the corresponding .tmx file contains an CSV-formatted list of the tile IDs used in each square. I copy that CSV data into an Excel-equivalent and make sure to format it all as text; from there I run "=DEC2HEX([cell] - 1, 4)" on every cell to obtain a hexadecimal halfword equivalent of each tile ID. I subtract 1 first because tile IDs in Tiles must start from 1, whereas FF1-DoS counts from zero.

At that point, we still need to make the data little-endian, so I copy the hex data from Excel into Notepad++ and use its column editing mode to remove the first column of 00's and insert a column of 00 at the end. This step obviously wouldn't work for tilesets that use tile IDs above 0xFF, but only the overworld does that, so in most cases it works out. I then copy the tile data into a separate .bin file and add the 8-byte header that all maps need; this header mostly just defines the map's dimensions. That done, I use BatchLZ77 to compress it, at which point the map data is ready to be inserted into the ROM, and I can update the map data pointer to point to the new map data I inserted.

So that's how the sausage is made. Far from elegant, but it works and doesn't take very much time once I got the hang of it...though a tool to automate and foolproof it would be handy. In general, I can leave the data for the tilesets and tile GFX/TSA alone if I just want to modify a map; editing those would be a separate process. Fortunately every aspect of a tileset is stored separately, so I can edit palettes without having to rebuild the tile arrangement data if that's what I want.

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #21 on: August 16, 2017, 03:10:07 AM »
Woah very creative of you Kea - using what you can (Excel) to do the job, respect!!!

Probably if you play a little bit more with excel formulas you can rearrange the little-endian too, so you may skip column rearranging and losing the precision for world maps. Try: =DEC2HEX(MOD([cell]-1,256),2) & DEC2HEX(([cell]-1)/256,2)

So the CSV contain the tile-map. Does tile ID is ID of actual tile (physical) or logical? FF5 combine 4 tiles in a logical tile (2x2 of physical). So the map uses IDs of logical units (2x2), not the physical ones.

Quote
I then copy the tile data into a separate .bin file
When you say tile data, do you mean tile bits or tile properties (flip, palette,..). And in general does Tiled provide tile/palette data in a raw format that can be injected in the ROM without transformation? Or that is the separate process you mentioned ...

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #22 on: August 16, 2017, 09:21:57 AM »
Thanks for the excel tip - I'm not much of a spreadsheet expert.

The tile IDs in the tilemap refer to the overall 16x16 tile, but as you say, this ID is used to piece together two layers of 8x8 logical units - one layer for the foreground and one for the background. For example, here's what the 16x16 tiles of Elfheim's item stores look like, with each tile using its assigned palette:

I ripped this and every other tileset by making a map with every tile from 0-255 in 16-long rows, taking screenshots ingame and stitching those screenshots together. Thus, every 16x16 block represents one tile.

But on the more basic level, the tiles graphics are really made up of 8x8 blocks with transparency; here's how the same tileset looks in the ROM with TSA applied:

When the game reads a tile ID, it uses that to index to a set of tile graphics to load; here's some of my notes on the subject:
Code: [Select]
At 0x68644
-Upon loading a map tile ID halfword:
-Take low 4 bits, multiply by 4
-Take upper 12 bits, multiply by 256
-Add together, add to (decompressed) TSA pointer
-If map type is 0x1 and you're outside a room, add 0x20 lsl 0x7 (0x1000); save in r12
-This way, if you're in a room you'll load different GFX
-Navigate to next tile data to overwrite(?) r10 lsl 0x5 + r7 lsl 0x1 + 0x4C + r4; save in r3
-load [r12], [r12+2] and store to [r3], [r3+2] (top left/right of tile)
-load [r12+0x80], [r12+0x82] and store to [r3+0x40], [r3+0x42] (bottom left/right of tile)
-Storing to tile map as 'background' tiles
-Top nybble is palette ID, rest are tile ID
-load [r12+0x40], [r12+0x42] and store to [r4 + 0x84C + count*2], [r4 + 0x84E + count*2]
-load [r12+0xC0], [r12+0xC2] and store to [r4 + 0x88C + count*2], [r4 + 0x88E + count*2]
-For 'foreground' tiles drawn in front of the above tiles and the player character (eg for armor stands)
-Same format: top nybble as palette, rest as tile ID

When you say tile data, do you mean tile bits or tile properties (flip, palette,..). And in general does Tiled provide tile/palette data in a raw format that can be injected in the ROM without transformation? Or that is the separate process you mentioned ...
I mean just the tile map/list of tile IDs, with a header on top to define the map width and height. Tiled doesn't provide raw palette or tile GFX data, so if I want to modify the basic graphics or palettes of a tileset I do indeed have to do that separately.

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #23 on: August 16, 2017, 10:16:45 AM »
Actually, here's a better-formatted example of the tile data. This is the Western Keep tileset, first using the 'interior' set, then the 'exterior' set.

The top-left part of the image signifies...something. Maybe to do with the TSA or GFX headers? I admit this isn't my area of expertise. The central column represents the background tiles; the right column are the foreground tiles, which are layered over their corresponding BG tiles at runtime.

Edit: The stuff on the left is indeed part of the header; TSA data in FF:DoS starts with a twelve-byte header which defines things like the size of one TSA tile (usually 2 bytes) and the total number of such tiles.
« Last Edit: August 16, 2017, 11:38:30 AM by Kea »

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #24 on: August 16, 2017, 05:35:25 PM »
OK got it, thank you Kea. Its pretty much the same as in FF5, but it uses only 2 layers (what you call background and foreground). FF5 uses 4 layers, the first two in similar way, the third is used for some effects and the last is black and white only and I think its used internally to determine where a player can move over the map.

I call the 16x16 pixels (2x2 tiles, or total of 4 physical tiles) logical tile, because that's how FF has determined its size and there is no hardware support for it (its not how it is in the VRAM, they don't have ID there). The 8x8 pixels tiles I call them physical because the hardware has support for them and actually they have ID in the VRAM.

BTW Does FF1 uses variable map width/height? Because FF5 the map size is fixed - 1024x1024 pixels ( 128x128 tiles, 64x64 logical tiles)?

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #25 on: August 16, 2017, 05:45:58 PM »
Gotcha, that makes sense. In FF1-DoS, whether a tile can be walked over, if random encounters can be found and such are tied to the (logcial) tile ID in a separate data structure.

FF1a does support variable map height and width. I'm not certain what the maximum dimensions and area are, but the overworld is 255x255 logical tiles for example. Most maps are much smaller of course. It may also depend on the map type.
« Last Edit: August 16, 2017, 06:01:56 PM by Kea »

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #26 on: August 24, 2017, 01:22:16 PM »
Haven't done much with FF1 lately (Dragon Warrior 2 and X-COM have taken up my free time), but here's a little thing: 16x16 icons for all of the 200 map sprite IDs in FF1-DoS:


I plan to use this with Tiled, to be able to place NPCs on the map as a separate layer, and in the future I'll do something similar for other types of map features. Making this work would require a tool to read properties from the tile layers and the map, and then format it for insertion - so I may end up asking for your help in this area after all Squall.

Interestingly, the big gray statues of the Fiends that guard the entrances to the Soul of Chaos dungeons aren't a separate map sprite - they use the same ID as the regular fiend sprites. Either their associated Event ID or some hardcoding by map ID makes them gray and motionless. I haven't looked into the exact mechanism yet.

Also look at that broken robot sprite next to the beaver. In the Soul of Chaos floor where it normally appears, it can take several different forms; this is probably also due to some map ID business. Nevermind! It's just determined by the facing/sprite index byte.
« Last Edit: August 24, 2017, 05:50:24 PM by Kea »

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #27 on: August 28, 2017, 01:36:29 AM »
so I may end up asking for your help in this area after all Squall.
Bring it on - now or never  :laugh:

Just kidding, but there was a movie with same/similar title so I couldnt hold not to write it :D

Squall

  • Dark Dragon
  • *
  • Posts: 486
    • View Profile
Re: FF1:DoS Projects
« Reply #28 on: August 30, 2017, 10:30:37 AM »
Haven't done much with FF1 lately (Dragon Warrior 2 and X-COM have taken up my free time) ...
XCOM 2: War of the Chosen is out :laugh:

Kea

  • Vargas
  • *
  • Posts: 94
    • View Profile
Re: FF1:DoS Projects
« Reply #29 on: August 30, 2017, 09:25:27 PM »
Don't remind me! I have enough on my plate these days  :tongue: