Messages

1

Map Requests / Re: "Tom and Jerry: Frantic Antics"

« on: August 05, 2025, 08:45:46 am »

Welcome to VGMaps.

Nice work on your maps so far, but I really hope that you only used JPEG, a lossy image format, for the attachments. A lossless image format like PNG is preferable for 2D maps to preserve the ripped images. High quality (low compression) JPEG might be okay for images with millions of colors like 3D maps though.

Manually stitching screenshots is something I did in my first mapping project to and it's tedious. One alternative is to try Maxim's autostitcher. It can stitch maps from a lossless video (something the BizHawk emulator can record). Record a video of playing a stage and then feed it to the autostitcher. Results may vary though.
https://www.smspower.org/maxim/Software/ScreenshotAutostitcher

However, I highly recommend looking into lua-scripting with the BizHawk emulator instead. You don't need a lot of programming experience to create scripts that can automate a lot of the stitching.
https://tasvideos.org/BizHawk
https://tasvideos.org/Bizhawk/LuaFunctions

I put together a lua-script for Tom and Jerry that you can use. The layers for the first three stages and the script can be downloaded from here:
https://www.mediafire.com/file/ycugr6or75fl6zs/Tom+Jerry+Frantic+lua+20250805.zip/file

Run the game in BizHawk and then select Tools -> Lua Console and open/run the script in the opened dialog to stitch the current stage. I only tried it on the first three stages, but it seems to work. Before running the script you can configure visible layers in GEN -> Settings. Set 'use custom backdrop color' to true to make it easy to remove transparent sections (magenta) in layers.

Personally I like to script-stitch the main and sprite layers separately and then compose them in an image editor. That way you can remove or move sprites on the maps in an image editor. The sprite layers I ripped are a bit messy and need to be manually reviewed. I hope you at least consider adding non-moving sprites to the maps. Makes them more complete IMO.

Feel free to ask if you have any questions.

2

Maps Of The Month / Re: 2025/07: Legend Of Mana (PlayStation) - mechaskrom

« on: July 26, 2025, 09:03:37 am »

Most Mana games aren't very satisfying to map because the "rooms" are disjoint (of course a Metroidvania map enthusiast would think that xP), so kudos for putting in all that work and making something interesting and useful!

Almost all the games I've mapped are "disjoint". It's a challenge to find good map layouts for them, but I kind of like that part in mapping projects. It's like putting together a puzzle with weird pieces that don't quite fit  .

I'm pretty happy with the layout of most of the LoM maps except Flames and Jungle. Theirs are really messy, but it was the best I could come up with after spending days trying out many different layouts.

I do have one tiny complaint though - the extra grey pixels in the text that were presumably added to smooth the font out for use at 2x size make it look blurry, and I kept checking if I was viewing the image at the correct zoom ): I think it would've looked better as just a straight Nearest Neighbor upscale without any smoothing. Or maybe even just 1x - the text is more legible large, but the maps are still at 1x and many details are hard to see without zooming in anyway, so the larger text doesn't have much benefit.

I only added grey pixels to the "thin" parts of characters. This made texts more legible when zoomed out (helps with downsampling fine shapes). I prefer maps that can be zoom fitted to the screen and still be used/read while playing the game so I don't have to constantly zoom in/out.

Doubling the font size was necessary to make texts readable even when zoomed out. A 1x font would've been way too small. 1x is what I use in the map title cards if people want to get an idea of just how small LoM's font is at its original size.

I don't find the 2x font with extra grey pixels to be distracting, blurry or too large even at 100% zoom, so for me it's only beneficial to the maps as texts are legible even when zoomed out a lot. Thanks for the feedback though, I'll keep it in mind for future mapping projects.

I've gotten some complaints over the years and almost all of them were about the maps' font: it's too small, too big, too blocky or too blurry. Oh well, it's hard to please everyone.

3

Maps Of The Month / Re: 2025/07: Legend Of Mana (PlayStation) - mechaskrom

« on: July 02, 2025, 10:47:29 am »

Thank you! 

Legend of Mana is a game I always wanted to play, but never got around to until last year. I thought it was pretty boring to play (too cryptic and unrewarding), but the graphics and music are amazing so I just had to map it.

It took me almost a year, which is the longest I've ever spent mapping a single game. Much of that time was actually spent just playing through the game multiple times and checking multiple guides to make sure I didn't miss anything (which I probably did anyway).

It's probably my biggest project too. I checked its folder and it contains 1662 png images and 399 paint net projects (mostly for dealing with layers). It was a lot of work, but I'm very happy with how the maps turned out.

The junkyard map is one of my favorites. That place is really confusing to navigate and in dire need of a map. It wasn't until I started mapping it that I realised it had two intertwined "sides" of similar rooms. A really clever and simple way to turn a place into a maze. I've never seen that construction before in any other game. Does anyone know of another game with a similar design?

There are many more 2D RPGs that I would like to map, but knowing how long time they take is daunting. 

4

Gaming / Re: Mini-Bosses... Favorites?

« on: May 31, 2025, 02:06:44 pm »

Guess you had a tough time trying to get to the end. Well, there's already maps, so no need to fret about getting by.

I beat it on an emulator with the help of a ton of savestates. The game punishes you hard for even the slightest mistake, so savestates help a lot. Savestates are also helpful considering it's a long game with no passwords, which it really should have had.

I wasn't thinking about mapping it. It was just a childhood game that I never beat and a game praised by many so I just wanted to finally play through it.

You like it? Really accentuates their technological style. Even in some stages.

Not sure. Hard to say without actually playing the game. It felt a bit overused, but on the other hand it gave the game a coherent and characteristic style. That's something I feel is important in games. If you can tell what game/series/company it is just by a random image or sound clip, then it has good characteristic/soul (not sure what's the right word).

5

Gaming / Re: Mini-Bosses... Favorites?

« on: May 30, 2025, 06:19:33 pm »

You mean Maximum Jumbo and Tri-Transforming Wall Walker? Oh, yeah.

I didn't know they had names. Thanks for telling me.

Thanks also for the concept art/development doc links. It's always interesting to see the groundwork behind a game.

I've only played "Blaster Master (NES)". It has some cool (and big for the NES) bosses for sure. Nice graphics and music too, but it's way too difficult. I also don't like the controls, especially with the Wall 1&2 upgrades. "Blaster Master Zero" looks fun though and something I want to play sometime.

I haven't played "Hard Corps: Uprising", but I took a quick look at some YT-videos and I understand why you pointed out the green lights style. It's everywhere.

6

Gaming / Re: Mini-Bosses... Favorites?

« on: May 26, 2025, 12:20:40 pm »

It feels like mini-bosses are a bit overlooked in games and that the "real" bosses are what people remember/talk about. I don't know when games started having mini-bosses, but it feels like they've been around for a long time.

I was thinking about my favorites and all I could think of was Konami's Contra series. There are a lot of mini-bosses (and bosses) in those games that I like. Two examples:
 -Contra: Hard Corps (Genesis), the big dancing robot in stage 1. It looks cool and also uses the Genesis's tilt layer scroll-trick in a neat way.
  https://youtu.be/3lyv5U9WTBQ?t=2048
 -Contra III: The Alien Wars (SNES), the wall climbing robot in stage 3. It's rare that games let you fight a boss while clinging to a wall.
  https://youtu.be/3lyv5U9WTBQ?t=1055

I don't know if Contra's mini-bosses count though. They're a good example of when mini-bosses are often bigger/worse than the bosses at the end of the levels. It's more like Contra has many real bosses per level rather than a few mini-bosses.

7

Mapping Tips/Guides / Re: Guide to mapping PlayStation (PSX) 2D games with PSVrammed

« on: May 15, 2025, 09:17:56 pm »

Thanks very much for sharing this! I've played around with VRAM tools for games before and it always gets tricky, I've stuck to emulator screenshots for the most part and trying to use codes to hide layers etc. I will definitely give this a try and check out your Lua scripts. The idea of trying to find the palette was always the part I dreaded, as it felt imprecise, but this seems like a fairly nice workflow.

Maybe I should write a PSX 3D mapping guide inspired by yours...

The lua script I made for LoM is not included because it's an embarrassing mess of code. I'm not a lua-programmer and it was made for one game use with no consideration for readability/reusability. Let me know if you really want it despite that.

It's not that interesting either since it's pretty much the same as all my other screenshot lua scripts. What it does basically in pseudo code:
-save origin state
-while cameraY < areaHeight
 -while cameraX < areaWidth
  -load origin state
  -set new camera position and write it to game (using codes)
  -run emulator a few frames so game is updated with the new camera position
  -take screenshot
 -endWhile
-endWhile

The origin state load before every screenshot is to keep animated/moving things in the same state in every screenshot. I think this could fail though if the game inserts lag frames at some, but not all, camera positions. Probably rare that it causes any stitching errors though and should be fairly obvious if it does. It's definitely better to use codes to freeze things, but I wasn't able to find any in LoM.


Finding the right palette can be a challenge sometimes, but unless the game was programmed by a bunch of monkeys they are usually ordered in a logical/structured way. Finding the correct palette will become easy after you've worked on a game for a while and gotten more familiar with how it uses VRAM. At least that's my experience having mapped a few PSX games.

Overall I've found this mapping method to be powerful and easy to use. In some ways it's actually better than the "normal" enable/disable whole BG/OBJ layers in emulators, because you can control every drawn object separately as long as they use textures/palettes in VRAM.


A PSX 3D mapping guide would be interesting so please consider writing one. I'm sure many others would also be interested in such a guide. I always like to hear about other mappers' process for mapping games. Perhaps I'll try mapping a 3D game someday, but as an old 2D gamer, one extra dimension scares me.

8

Mapping Tips/Guides / Re: Guide to mapping PlayStation (PSX) 2D games with PSVrammed

« on: May 13, 2025, 12:02:21 pm »

Next we will do a bit more complicated example which uses color blended layers.

PSX has four blend modes/operations. The calculation done per color channel (RGB) for each mode is as follows:

Code: [Select]

1:   N = B>>1 + F>>1   (average, 0.5B + 0.5F)
2:   N = B + F         (add)
3:   N = B - F         (subtract)
4:   N = B + F>>2      (add 1/4, B + 0.25F)

'B'  = value already in the framebuffer
'F'  = value being written to the framebuffer
'N'  = resulting value in the framebuffer (clamped to 0-31, 5-bit)
'>>' = bit shift right operator

Here's how they look like. From left to right: normal, mode 1-4.


Legend of Mana mostly uses mode 2 and 3 which will make the drawn graphics have a bright (good for lights) or dark (good for shadows) transparency effect. The PSX blend modes are different from actual alpha blending that you're probably used to seeing in games and one of many factors which give PSX games that special "PSX look". Incidentally, I believe the SNES has something similar to mode 2 and 3 blending and I actually like the look of this kind of blending.

It can be difficult to see the priorities of blended layers so a tip is to set the layers' palettes to different solid colors to make it easier to tell layers apart.


I strongly suggest ripping blended graphics with the alpha bit cleared because otherwise it's very easy to get wrong results if you don't know exactly what you are doing.

Let's map a section from Norn Peaks (the one after the wind village) in LoM which uses a scrolling fog effect in the foreground. The fog is actually two layers which each use a 4-bit palette. The fog palettes are located at X,Y=80,472 and 96,472 in VRAM.

Remove the fog by setting both palettes to transparent black. After the main layer is stitched without any fog we can continue with ripping the two fog layers. Use the edit invert function to remove all palettes except the two for the fog we just cleared.

Before ripping the fog we want to clear all alpha bits in the two palettes to disable color blending. Move the palette marker to each fog palette and press the P-key. With the alpha bits cleared we can go ahead and rip the two fog layers. Just clear one of the fog's palette to transparent black and rip the remaining fog layer. Undo the clear fog edit and repeat for the other fog layer.

Both fog layers repeat horizontally every 256 pixels so they can be copy pasted in 256 pixel wide chunks until the whole main layer is covered.

To blend ripped layers I made a plugin for paint.net. It's called PS1Blend and can be found on my github. To use it you specify the blend mode in layers' name (**1, **2, **3 or **4), add and select an empty layer to write the result to and then run the plugin.

Both fog layers use blend mode 2 so the paint.net project for this example would look like this (name and order of layers):
layer 4 blend result
layer 3 fog2 **2
layer 2 fog1 **2
layer 1 main

This concludes my short introductory guide. Mapping areas can get really complicated (I hated Mekiv Caverns, Madora Beach and Home in LoM), but I hope this guide is enough to get you started. Feel free to post any questions, comments, corrections, etc.

The images and paint.net-projects used in this guide and more can be found here:
https://www.mediafire.com/file/v9zoj0tqnip9aim/PSVrammed_guide_assets_20250513.zip/file

GitHub links:
https://github.com/mechaskrom/PSVrammed
https://github.com/mechaskrom/PaintNet-PS1Blend

9

Mapping Tips/Guides / Re: Guide to mapping PlayStation (PSX) 2D games with PSVrammed

« on: May 13, 2025, 11:49:20 am »

Let's continue with an example of how you would map the entrance of Luon Highway in LoM with PSVrammed. I wrote a BizHawk lua-script for LoM that will screenshot-stitch an area and if we run it we will get this:

The result will have an ugly "seam" in the back mountains because that layer scrolls at a different speed than the camera (main layer). We need to isolate the different layers (back+main) and rip them one by one instead.

Make a savestate in BizHawk (e.g. Shift+F10) and open it with PSVrammed. Now we need to locate the palette (or palettes) that the back layer uses. Change to 8-bit palette editor mode (Ctrl+F2) and move the palette marker between the different palettes until you find a likely candidate (look for the mountains to appear in the BG textures area). Press enter to open the edit palette dialog and set the full palette to magenta. Save the changes (Ctrl+S) and reopen the savestate in BizHawk (F10). If we changed the right palette (it's an 8-bit palette located at X,Y=0,473) the back layer will now be magenta. In case we changed the wrong palette, just undo the edit (Ctrl+Z) and try again with another palette.


BizHawk result:


With a solid colored back layer we can now rip the main layer without problems. After that's done we just need to rip the back layer too. We could change all palettes except the back layer's to transparent black (RGB=0,0,0), but a faster way is to use the edit invert function in PSVrammed. Change the size (Ctrl/Shift+PageUp/PageDown) and position (arrow keys) of the texture marker so it encompasses the palettes and then press the I-key. This will write 0 (default edit value in 4- or 8-bit mode) and then undo the full palette magenta edit. All palettes will now be transparent black except the restored back layer palette that we edited in the first step.


BizHawk result:


Finally use your favorite image editor (I like paint.net) to change the magenta to fully transparent and compose the main and back layers. The back layer repeats horizontally every 192 pixels so it can be copy pasted (tiled) in 192 pixel wide chunks until the whole main layer is covered.

The next section of Luon Highway uses the same textures and palettes as the first. It's common in games that sections do this. This means that the edits to isolate the main and back layer will be the same as in the first section. PSVrammed can save a sequence of edits and perform it on other savestates to save work and time. Save the edit sequence after isolating the main layer and then again after the back layer. Edit sequences can be bound to the number-keys (0-9). If everything is setup correctly, you will only have to press a few keys to rip similar sections.

10

Mapping Tips/Guides / Guide to mapping PlayStation (PSX) 2D games with PSVrammed

« on: May 13, 2025, 11:36:08 am »

A few people have asked me how I did my Suikoden maps so I thought I would write a short guide for the method I use to rip graphics from PSX 2D games. It mainly depends on a program I wrote when mapping Suikoden 2. This program was also used for my Suikoden 1 update and Legend of Mana maps. In this guide I'll use LoM (Legend of Mana) and the BizHawk (PSX octoshock core) emulator in the examples.

The program is called PSVrammed (available on my github page) and it can extract and edit VRAM (video memory) in emulator savestates. It relies on the fact that PSX games don't often change VRAM. Edits in VRAM will usually remain until you trigger a loading screen. I started experimenting with VRAM hacking when mapping Suikoden 2 and it worked so well that I created PSVrammed. With it you can isolate different "layers" in an area and map them one by one. It's also useful for removing things (like sprites) you don't want in screenshots.

The PSX GPU (graphics processor) has 1MB VRAM which fits 1024*512 of 16-bit pixels. The major parts stored in VRAM are framebuffers, textures and palettes (also known as CLUTs, color lookup tables). Palettes are 16-bit and so are framebuffers usually too. Textures are usually 4- or 8-bit which means their pixels are indices to a palette with 16 or 256 colors (16-bit).

16-bit pixels have 3*5=15 bits for red, green and blue, and one alpha bit. The alpha bit is used for masking and blending (semi-transparency) effects. 5 bits give each color channel a decimal range of 0-31. A zero black color (RGB=0,0,0) is normally not drawn by the GPU and used for fully transparent pixels.

I recommend checking online for more info about the PSX's GPU and VRAM. It's good to have some basic knowledge about them when using PSVrammed and mapping PSX games.

Here's an example of VRAM from LoM (Legend of Mana):

LoM uses a very typical VRAM layout. PSX games don't have to use this layout, but it's very common. In the example I've also marked in yellow where LoM stores palettes and textures for backgrounds (BG). LoM uses a mix of both 4- and 8-bit for its backgrounds, but sprites are usually only 4-bit.

11

VGMaps Social Board / Re: Happy (belated) 23rd birthday to VGMaps.com!

« on: May 08, 2025, 05:52:15 pm »

Happy birthday!

Thank you for creating and running this fantastic site. Feels like it's pretty rare that internet sites are around for this long. Most sites I used to visit back in the days are gone now or have changed dramatically. The only ones still here without major changes that I can think of at the moment are VGMaps and GameFAQs.

12

Maps In Progress / Re: New maps from a new member

« on: May 08, 2025, 05:33:11 pm »

Welcome! I look forward to seeing your maps.

I played Battle City (NES) a lot with my brother when we were young. It was one of the games on a 31-1 multicart my older brother bought from a shady ad. Good times! 

13

Map Requests / Re: JonLeung's Requests

« on: May 08, 2025, 05:00:36 pm »

mechaskrom has mapped a great action RPG, Legend Of Mana!

All the Mana games are so colourful and detailed.  Is this not one of the most gorgeous games on the original PlayStation?  Probably one of the best-looking games with hand-drawn graphics, like, ever, even.  Free from the need to use tiles (like on the Super NES) and not bowing to that generation's push into 3D polygons, just about every screen or room looks like a painting.

I remember when I saw pictures of Legend of Mana at its release and were blown away by the painting-like gorgeous graphics. I actually never got around to play it until now though . The graphics and music is amazing, but I found the game to be pretty boring to play. Secret of Mana on the SNES is much more fun in my opinion.

I like that mechaskrom indicates how all the rooms are connected and what is in each chest, and though that is expected of RPG maps, the treasure contents are listed aside and the paths connecting screens never go over the games' graphics themselves, allowing us to see each room with no obstructions.  Now that's how you map a beautiful RPG!

I'm glad you noticed. As you alluded to, I didn't want to cover up any of the beautiful graphics so I kept all markings outside all rooms. The maps are thereby booth marked and unmarked at the same time . Fortunately this worked quite well for this game as most rooms are small. Most likely a consequence of the graphics (PSX's 1MB VRAM isn't much for this kind of style).

14

Gaming / Re: Crater, a Sokoban clone for MS-DOS

« on: April 22, 2025, 12:40:59 pm »

I thought it was a solid sokoban game with nice graphics and good puzzle and interface design. It having a story with a short intro and ending was a nice touch as well. The difficulty felt fair with a nice mix of easy, medium and hard levels. There were only three levels I got totally stuck at (I gave those a 10 rating) and had to use a sokoban solver (Sokoban Automatic Solver by takaken) on.

Overall I liked your game very much and didn't find anything particular to complain about. Good work!

15

VGMaps Social Board / Re: What 2D Game Engines are best for making levels and their maps?

« on: April 08, 2025, 12:08:09 pm »

Isn't the Hatch Game Engine just a code framework/library and you have to code/write your game around it? I.e. it's not a visual game maker program like Game/RPG maker or Clickteam Fusion.