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 - mechaskrom

Pages: 1 [2] 3
16
Maps Of The Month / Re: 2017/02: Solar Jetman (NES) - mechaskrom
« on: February 10, 2017, 08:34:09 pm »
Thank you!

Solar Jetman is an old favorite. It's a hard game, especially the final planet and its auto-scroller section, and the controls takes a while to get used to. It's also a bit repetitive with almost the same objective on 13 similar looking planets. But the graphic is good, the music is very atmospheric, dealing with gravity and inertia is an interesting concept and overall it's quite entertaining to explore the mysterious large planets. Luckily warps exist so you don't have to clear all planets (I wonder how the skipped ship parts were collected though?) and choosing a route is also an interesting part of the game. My favorite is taking the warp on planet 3 to planet 6 and there take the warp to planet 10. Not the shortest way, but one of the easiest. You also got to love Rare's humor. A planet named Shishkebab and some of the treasure chest contents and analyses are also funny: http://www.mediafire.com/file/7c21posdu1o4g31/solar_jetman_humor.png
Can anybody explain why a robot kit apparently consists of marine species? Some joke I'm missing? :)

Solar Jetman mysterious feel is also helped/caused by its succinct manual and leaves it up to the player to discover most things. Even today I learn new things about it. In FatRatKnight's TAS I learned that you can spin orange crystal for bonus money and that there is a short-lived warp on planet 1. While mapping I also discovered a similar warp on planet 4. Rare really like these kind of warps in their games e.g. Snake Rattle 'n' Roll and Battletoads. The orange crystal spin is a game-changer and the extra money makes things a lot easier. You can even do this infinite times if you release the crystal before the final spin for ridiculous amounts of money. I used to wonder why the little green enemy ships went berserk whenever you towed an orange crystal. Now I know why. :)

Mapping this game was quite hard, but thankfully I found some useful codes from TASVideos. Together with some I found myself I could put together a lua-script that screenshot whole levels. I also looked at the ROM-file and realized that Solar Jetman uses 128x128 pixel metatiles. That is big. Most games use something like 16x16 or 32x32. Here is an image with a grid and index (white number) overlay to make it more obvious: http://www.mediafire.com/file/574t79drdem7y5n/solar_jetman_metatiles.png
Index is an 8bit value so max number of metatiles is only 256, but they can have different pattern sets and palettes so it's not that bad. Thanks to the big metatiles all level-layout in the game only takes a few kilobytes in total and explains how Solar Jetman could have such huge levels. Detail and variation of level's structure suffer with such big metatiles, but I think the game-designers managed to hide that well and make interesting layouts with them anyway.

The metatiles are also used to directly render the pretty good in-game maps instead of storing them. Each metatile is converted to an 8x8 pixel map tile. It's probably because of this that the map screen takes longer to bring up on the bigger planets. This also means that all levels can be viewed in the in-game map viewer with some trickery. Here is planet 13's ship part level for example: http://www.mediafire.com/file/uacvrn8z9op25wl/solar_jetman_planet_13_part_map.png
The in-game map renderer uses a fixed width and will use whatever data comes next to fill the whole width and not stop drawing rows until the height of the level is reached. So on narrow levels that means the renderer will continue with the next row (levels are stored linearly, 1D) and whatever comes after the level. The infamous Preludon map is also a great example of this behaviour. You can see the start of planet 4 on the last row which happens to be stored after planet 1.

There are many interesting things in Solar Jetman to talk about, but this post is already to long. I'm very happy with the resulting maps. It's pretty awesome to look at the huge planets (both zoomed in/out) and the mini-maps are very helpful when playing the game. I'll finish with this funny spot on comic.

17
Maps Of The Month / Re: 2016/08: Suikoden II (PSX) - mechaskrom
« on: September 10, 2016, 05:23:53 pm »
Thank you for the translation. That comment is pretty funny and true.  :)

18
Maps Of The Month / Re: 2016/08: Suikoden II (PSX) - mechaskrom
« on: September 09, 2016, 09:53:01 pm »
Suikoden 2 have a lot of weird stuff off screen. I like that "programmer/artist note" in the north of Greenhill. I wonder what that japanese text says? Probably something like "AREA E" also?

You can take a boat from Radat Town, that you actually are in control of, to get to Banner Village (it is the only way to get there the first time). Magician's Island in Suikoden 1 can't be seen on the world map normally that I know of so there you remember correctly.

19
Maps Of The Month / Re: 2016/08: Suikoden II (PSX) - mechaskrom
« on: August 02, 2016, 03:35:19 pm »
Thank you!

It took a lot of time to map this game, but I'm very happy with the result. Suikoden 2 has really nice graphics and a lot of details, especially in the cities, so having maps of the areas and be able to see all of it is satisfying. It's a real shame that a lot of the offscreen areas are incomplete, for example Milich's house in Gregminster or the two mansions in Kyaro (probably the most beautiful place IMO). I didn't want to change the game's original graphics so the maps are mostly rips straight from the game regardless of how incomplete they are. But seeing what the designers did or didn't do is also interesting in a way.

Suikoden 2 fortunately has relativily simple graphics with few animated background objects, only 1-2 scrolling layers, etc, so it was pretty easy (but still time consuming) to map. The only effect that caused some problem was the water-effect used on the world and in a few cities. I'm talking about that static background layer with a dithered gradient which looks awful IMHO. I had to replace it with a solid color and I hope that my choice wasn't to bad.

I didn't find anything to interesting when mapping Suikoden 2. There is an unused small room in Tinto which probably was meant to be that locked tool shed. There is also an unused small room in Headquarters. So nothing here like that big unused room in Gregminster Palace in Suikoden 1.

20
My ideal strategy to keeping the enemy at bay was have a line of five footmen/grunts at the front of a bridge or small gap with five archers/spearmen right behind them (with three to five catapults behind them if available).

Pretty much my strategy to and almost the only way to beat the computer player. And to attack you moved these groups near the target and used a bait to lure only a few units to their death.  This defensive strategy made the first warcraft feel very unique and interesting. Very different from other real-time strategy games I have played. The control is a bit clunky, but this is still my favorite warcraft game and it is wonderful to see maps for it. Congratulations Will and thank you.

21
Maps Of The Month / Re: 2014/12: Solstice (NES) - Guillaume Saint-Amant
« on: December 06, 2014, 10:38:03 pm »
Congratulation! This map deserves it.

It has a lot of detail and info, but is simple to read and looks beautiful. The layout is really clever. In short, you made a really great map. :)

Solstice is an old favorite, great game with awesome music, and I'm really glad to see it getting a nice map.

22
Map Requests / Re: Nintendo Power - 1988-1996 cover games
« on: November 27, 2014, 09:32:28 pm »
I can map swords and serpents if nobody is already working on it. It is an old favorite and I even drew my own maps for it when I played it many years ago (almost had to to beat the game). I've always wanted to make some more professional maps for it so this would be perfect.

23
Maps In Progress / Re: Tropicon's map projects
« on: December 21, 2013, 09:14:07 pm »
@TerraEsperZ
I'm still working on Suikoden 2 and it will take me a few more months to finish. However, I understand how you feel and agree completely with your post. High standards are definitely one factor that make projects more difficult and time-consuming. But I appreciate high quality maps and I'm probably not the only one.

Suikoden 1 maps took me about 5-6 months (2-3 hours per day) to finish and Suikoden 2 will take even longer. The sequel is a bit bigger than the first game, but the biggest reason it will take longer is that I wanted to create a few tools to help me map games. So hopefully my future projects will be easier (especially psx games) at least.

I don't think people realize how much work and time it can take to create a map (unless they have done it themselves) so I find it impressive how many maps some mappers like Trop, TerraEsperZ and many others manages to complete. So big kudos to all contributors to vgmaps. :)

24
Map Gab / Re: Umihara Kawase [COMPLETE]
« on: May 13, 2013, 03:20:23 am »
I think the maps look great and that you choose a simple and good way to handle "animated" graphics in static maps. Great work and congratulations to your first complete project.

And thank you for considering me as a co-author, it's a real honor. Though I think my part in this project was pretty insignificant, but if you insist. :)

25
Map Gab / Re: Umihara Kawase
« on: April 30, 2013, 07:28:29 am »
I would choose static unanimated png maps.  They are easy to view and are probably what most people want as a map.

But if you have the time and energy it would of course be great to also have animated versions of the maps. I don't know what is the best way to do animated maps though. Besides GIF and HTML, perhaps flash or lossless video? But maybe that could cause a problem with big file sizes?

26
Map Gab / Re: Umihara Kawase
« on: April 23, 2013, 01:17:05 am »
The sprite ripper is ready for testing now. Check your messages.
Let me know if you find any errors/bugs.

One thing I noticed. There are no sprites for the player (Kawase?) at least not in the files you sent me. Where is she? :)

And finally....
You gotta love the sprites in this game. Fishes with legs? The attached sprite always cracks me up. :D
Ah, good old games. You rarely see this in modern games. :(

27
Map Gab / Re: Umihara Kawase
« on: April 19, 2013, 06:10:23 am »
Made som big progress with the sprite ripper and I'm pretty sure it's working correctly now. But because I dont know how the sprites should look like there could always be some errors left (although they look fine to me). :)

Quote
A sprite sheet should be exported PALAM times, one sheet for each palette.
Aha, that makes sense. Should be easy to fix.

Just to be clear. Do you want a transparent strip/spacing between sprites or no strip/spacing at all?
See EDIT.

Some more questions/remarks:
There are three things that are strange that I discovered when running the ripper on all 55 files.

The amount of sprites specified in the header (sprAm) is often smaller than the amount of sprites that fits between sprAddr and the following address (always(?) palAddr). Take U3_KNG.bin for example.
sprAddr=0x00000088=136
palAddr=0x000000A0=160
sprAm  =0x0005=5
bytes per sprite = 4
(160-136)/4=6
So there is space for 6 sprites but sprAm  = 5. I don't think the extra sprites depict anything, so I guess this doesn't matter anyway. I just thought it was a bit strange. All the other amounts specified in the header conforms to the calculated amounts for all files.


I don't think the sprite's block amount is 2 bytes in size. The sprite format seems to be more like this:
Code: [Select]
addr.+ AM UU FROMB-.
$088 | 02 00 00 00 |
$08C | 03 00 02 00 |
$090 | 03 00 05 00 |
$094 | 03 00 08 00 |
$098 | 03 00 0B 00 |
-----+-------------'
AM = amount, 1 byte
UU = unknown?, 1 byte
FROMB = from block, 2 bytes

If you treat amount as 2 bytes you get values (both signed and unsigned) that can't be right.

I don't know what the unknown byte does, but of all 55 files only the two MSB seems to be used. They could be some kind of flags? So the format of the unknown byte seems to be:
ff------
where
ff=flags?
-= never used?


And last (I treat amount as one byte here).
Block amount is = 0 for some sprites in two files (U3_SMOKE.bin and U3K0_PR0.bin).
What can this mean? Something to do with the flags in the unknown byte? The sprite is disabled?
For now, I treat this as a disabled sprite (8x8 blank/transparent) and that looks fine in the spritesheets at least.
But perhaps I'm wrong with amount = one byte?


I've uploaded the logs from the files that the sprite ripper doesn't like 100%. :)
And I also included the spritesheets from the two files with "disabled" blank sprites.
The logs are divided into 3 folders and hopefully the foldernames indicate what the ripper didn't like with them. Link:
http://www.mediafire.com/?gvz8nndxwf1gc86

Perhaps they could help you figure things out?


EDIT:
About the spritesheet output again. Isn't it problematic to set all spacings (non sprite pixels) to transparent? I used dark cyan because it makes it easy to see how big the sprites are, but perhaps you don't need to know that to use the sprites? I could always make it an command line option so you could chose between a transparent (default?) or a dark cyan background.

I checked all unused sprites (after sprAm) and they all have block amount = 0 and a size of 1x1, so they are "disabled". I'm just wondering why they are even there? :)

And before you made the last post I changed the program so it accepts both a single file or a folder. :)
I needed that to test all bin-files anyway.

28
Map Gab / Re: Umihara Kawase
« on: April 18, 2013, 07:04:31 am »
Quote
The program works exactly as I intended! Using a mono command line tool on Mac for the first time proved no challenge either.
Wonderful! Both that the program and mono is working. :)

Reverse-engineering the sprite-format isn't that important, but could be interesting. But it seems to be a lot of work and I don't know 658c16 assembly unfortunately. So in the end it's probably not worth the trouble.


Getting the sprites from the DS-version seems to be a novel idea. :)
I started working on a program to extract the sprites, but the format is complicated so this turned out to be harder to make than the field tilemap extractor. I've got something working, but I'm very uncertain of how correct it is so I'll need more time to check the output of it and so.

Now a few questions to Raccoon Sam, if you don't mind:
-Spriteblocks always use palette 0 you say, so what's the point of PALAM if it can be higher then 1? I think I'm missing something here. Why can a bin-file have multiple palettes if only one is used for all spriteblocks?

-How do you want to specify the input to the program? One file or one folder with files? Running the program for every bin-file seems tedious so it perhaps is better to give it a folder?

-How do you want the output from the program?
-Save every sprite in a bin-file as a png-file?
-Save all sprites in a bin-file in one png-file (spritesheet)?
-Other? I toyed with animated GIFs, but .NET doesn't support that good enough to satisfy me (the output quality is horrible even for small low color images). But if you really want that I could perhaps look into it more.



And TerraEsperZ, don't worry. You have to be a genius to understand all of this instantaneously. My head hurt just looking att Raccoon Sam's wall-of-text post. :) But if you give it time and process it in small steps it will usually become clear.


FYI, a more correct term for "reading bytes backwards" is little-endian:
http://en.wikipedia.org/wiki/Endianness
and it's very common.


Don't be modest Raccoon Sam. I think you've done some excellent hacking with Umihara Kawase so far.
And don't underestimate trial and error. That's my modus operandi when I'm programming. Powerful stuff. :)


Quote
Though my documents prove useful, I think the real wizard here is mechaskrom. After all, without him, all we'd have is a nice recipe but no cake.
Thank you. Very kind. ....I like cake. ;)


The image of every map is impressive. :O
But why is one field up side down? And some fields seems to be repeats of earlier levels. I haven't played Umihara Kawase so perhaps it should be so?


Finally, I've attached the spritesheet-output from the program of U3_KNG.bin
The dark cyan strips are just spacing between the sprites so you can easily tell them apart.
So the first sprite is 32x24 pixels big, the following 4 are 32x32.


I need some sleep now...  ???

29
Map Gab / Re: Umihara Kawase
« on: April 12, 2013, 12:38:38 am »
@Raccoon Sam
First version of the tool is finished. Check your messages.

Thanks to Raccoon Sam's great analysis it was pretty straightforward and painless. :)
Minor correction though. Graphical characters are loaded from 0x20C13.

And I would like to show everyone the tilemap output. I thought it looked pretty cool with the psychedelic colors. :)

30
Map Gab / Re: Umihara Kawase
« on: April 09, 2013, 01:33:37 am »
Mono for Mac should work fine. I'll just make sure it works in mono for windows. But perhaps you don't want to install mono?
I don't have Mac or any experience programming for it so mono is the best I can offer.

Your instructions seems to be clear, but I'll ask you for clarifications if needed.

I'll will start working on the tool and see how it goes. :)

Pages: 1 [2] 3