Porting Cyberdogs to Super Nintendo

Discussion of hardware and software development for Super NES and Super Famicom. See the SNESdev wiki for more information.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
Post Reply
none
Posts: 117
Joined: Thu Sep 03, 2020 1:09 am

Porting Cyberdogs to Super Nintendo

Post by none »

In case you don't know the game, it was a freeware arcade game for DOS. Here's a yt video about it: https://www.youtube.com/watch?v=GHNNCeIo4-M

The author released the source code in 2000 or so.

The games old website is archived on archive.org: https://web.archive.org/web/20000408233 ... rdogs.html

I'm thinking about making an SNES port for this game and I'd like to share some thoughts about this.

The source code is available on the website and I've looked into it for a bit. It is all written in Turbo Pascal but it's really nicely written and well organized so it's easy to understand and 90% should be straightforward to port, except graphics, sound and input code of course.

Now since rewriting everything in assembly seems very tedious to do, I wonder if there's a better alternative... maybe there is a Pascal compiler which can generate 6502 or even 65816 assembly? If not, maybe there's a pascal compiler that is open source and which could be adapted to do so? Maybe much of it could be done through simple search and replace / macro expansion? Is there anything that can convert Pascal to C code? In most spots, performance should not be an issue.

About the games graphics, the backgrounds in the original game use 32x24 tiles so they should be pretty straightforward to convert (composing them out of 8x8 tiles). Player graphics, enemies etc obviously can be done with sprites and so could the UI (just a few icons in in the top left corner and now and then some short text messages).

The two player mode (horizontal splitscreen) could be implemented by using a different bg layer for each player and using the windowing registers.

Since the screen is considerably smaller than in VGA (256 px vs 320 px), however, the visible area could get very small (it is already quite tiny in the original), and I don't have a good solution for this.

Making the minimap could also be problematic since it is rendered pixel by pixel. I think it can be kept entirely in VRAM in the 2bpp layer assuming mode 1 is used for the game and maybe overlayed with blending. But I'm not sure whether there is enough VRAM left after allocating all the zombie sprites etc; In fact I'm not too sure about there being enough VRAM for everything at all and I have to look into this a little more.

About controls, the original has a fire and a strafe button which you hold down to keep the direction you are facing. I'm thinking about implementing an alternative control scheme where the A,B,X,Y buttons shoot in directions instead (like in Smash TV), using L and R for changing weapons, while still allowing to use the original control scheme (selectable via the options menu).

The game areas are generated randomly, so they have to live in RAM, but that is fine since they are quite small. An issue with the games RNG is that it uses the random generator from Turbo Pascal's standard library and so that would have to be replicated exactly in order to get the original campaigns (which have a fixed seed).

What do you think about this? Any limitations that might come into play that I haven't considered?
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Porting Cyberdogs to Super Nintendo

Post by calima »

Why not use one of the modernized SDL ports, instead of the original ancient source?
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Porting Cyberdogs to Super Nintendo

Post by 93143 »

It doesn't look to me like it should have a VRAM problem - though of course I haven't actually done any real analysis; this is just from eyeballing the apparent complexity of the onscreen graphics.

You have 16 KB for sprites, which is enough for 32 unique 32x32 blocks, or 128 16x16 blocks, or 512 8x8 tiles, and all of the zombies seem to be palette swaps of each other except for the heads. Assuming you don't do any daring tricks to expand the sprite area (the only way I know is to rewrite OBSEL midscreen, which doesn't seem like it generalizes to this style of game), you then have 48 KB for everything else.

If you must use 8x8 tiles for the BG layer instead of 16x16, you will probably need to use at least 4 KB for the main layer tilemap, suggesting ~6 KB used including the minimap (and HUD?). Two-player mode requires three tilemaps including the minimap, but it uses a vertical split, so you can just use a 2 KB map for each player. This leaves 42 KB for tile data, and from what I've seen in that video I don't see you blowing through that.

The invisible terrain feature is interesting, and suggests that there will be a lot of wholesale map rewriting. If you can limit the number of simultaneously displayed BG tiles to 256, you can rewrite the map twice as fast, but that may not be possible (as numerous Mode 7 games attest, 256 tiles is not a lot). Also, if I'm not mistaken, you can put the two 2-player maps right next to each other in VRAM, and if you're rewriting the whole map on a regular basis you can pretty easily switch between two 2 KB maps and one 4 KB map on the fly.

You may want to consider reconverting the graphics for the SNES aspect ratio. This would mean that a 32x24 block on the original would be converted to 24x24 on SNES, and the visible action area would end up about the same - a bit smaller horizontally, a bit bigger vertically. It might also make the sprite graphics easier to fit, if that becomes an issue (the resting zombie sprites appear to be 17 pixels wide).
none
Posts: 117
Joined: Thu Sep 03, 2020 1:09 am

Re: Porting Cyberdogs to Super Nintendo

Post by none »

calima wrote: Wed Jan 19, 2022 11:30 am Why not use one of the modernized SDL ports, instead of the original ancient source?
I didn't know about those, thanks, it's probably worthwhile to look into them.
93143 wrote: Wed Jan 19, 2022 2:35 pm It doesn't look to me like it should have a VRAM problem - though of course I haven't actually done any real analysis; this is just from eyeballing the apparent complexity of the onscreen graphics.


You have 16 KB for sprites, which is enough for 32 unique 32x32 blocks, or 128 16x16 blocks, and all of the zombies seem to be palette swaps of each other except for the heads. Assuming you don't do any daring tricks to expand the sprite area (the only way I know is to rewrite OBSEL midscreen, which doesn't seem like it generalizes to this style of game), you then have 48 KB for everything else.

If you must use 8x8 tiles for the BG layer instead of 16x16, you will probably need to use at least 4 KB for the main layer tilemap, suggesting ~6 KB used including the minimap (and HUD?). Two-player mode requires three tilemaps including the minimap, but it uses a vertical split, so you can just use a 2 KB map for each player. This leaves 42 KB for tile data, and from what I've seen in that video I don't see you blowing through that.
Yes, I guess you're right, I was being too pessimistic about this initially. However there is also different stuff like the frames of the explosion and the different weapon icons which are quite large.

93143 wrote: Wed Jan 19, 2022 2:35 pm The invisible terrain feature is interesting, and suggests that there will be a lot of wholesale map rewriting. If you can limit the number of BG tiles used to 256, you can rewrite the map twice as fast, but that may not be possible (as numerous Mode 7 games attest, 256 tiles is not a lot).
There are a few things that should make this easier: The map doesn't update very often, only as you move across tile boundaries, it probably wouldn't be noticeable if the calculations / map updates had to be spread out across 2 or 3 frames. Also there aren't that many tiles visible at any time so the actual visibility calculations themselves should be quite fast. And only those parts of the map which actually change would need to be updated although it's doubtful if that would be faster than just DMAing the whole thing. It should be possible to just update the high byte of the tilemap, and make the tiles all black by changing the palette (reserving one palette for all black colors) - the high byte would need updating anyways because the tile should hide the sprites in the black areas meaning that the priority bit would have to be set.
93143 wrote: Wed Jan 19, 2022 2:35 pm You may want to consider reconverting the graphics for the SNES aspect ratio. This would mean that a 32x24 block on the original would be converted to 24x24 on SNES, and the visible action area would end up about the same - a bit smaller horizontally, a bit bigger vertically.
I have thought about this too. One could even make them still smaller and use 16x16 tiles instead. Then 16x16 tilemaps could be used, which would cut down on the visibility update costs. In both cases (24x24 and 16x16), scaling down the sprites without messing them up would require at least some amount of hand pixeling new graphics, which I'd want to avoid....also I'd probably want it to resemble the original as closely as possible.

I think in a first step, I'll convert all the graphics and try to fit them into tilesets, if that works, I guess I'll stick with the original artwork for now.
93143
Posts: 1717
Joined: Fri Jul 04, 2014 9:31 pm

Re: Porting Cyberdogs to Super Nintendo

Post by 93143 »

none wrote: Wed Jan 19, 2022 3:17 pmYes, I guess you're right, I was being too pessimistic about this initially. However there is also different stuff like the frames of the explosion and the different weapon icons which are quite large.
Well, like I said I haven't done any analysis. I'm just going by the fact that it doesn't look all that complicated for a SNES game. On the other hand, Sonic the Hedgehog didn't look too bad either, and the sprite memory constraint turned out to be fairly tricky to work around...
It should be possible to just update the high byte of the tilemap, and make the tiles all black by changing the palette
I hadn't thought of that. Good point.
scaling down the sprites without messing them up would require at least some amount of hand pixeling new graphics, which I'd want to avoid....also I'd probably want it to resemble the original as closely as possible.

I think in a first step, I'll convert all the graphics and try to fit them into tilesets, if that works, I guess I'll stick with the original artwork for now.
It's your port, of course. Either way is a tradeoff.

I'd just like to note here that I've found a decent way of rescaling sprites that reduces the amount of hand work necessary. I use GIMP for this. If I establish an indexed image with just the colours found in the sprite, take an RGB version of the sprite and rescale it using a high-order algorithm, and then copy+paste the result into the indexed image, only a small amount of manual touch-up is generally required.

You do, however, have to watch out for alignment issues, as rescaling sprites with different destination grid alignments could cause the result to not match between frames even in areas that should be identical. The graphics for this game are simple enough that this may not cause a ton of headaches - I shudder to think of getting halfway through converting Metal Slug's sprites and realizing I botched the alignment...
Myself086
Posts: 158
Joined: Sat Nov 10, 2018 2:49 pm

Re: Porting Cyberdogs to Super Nintendo

Post by Myself086 »

none wrote: Wed Jan 19, 2022 3:17 pm There are a few things that should make this easier: The map doesn't update very often, only as you move across tile boundaries, it probably wouldn't be noticeable if the calculations / map updates had to be spread out across 2 or 3 frames. Also there aren't that many tiles visible at any time so the actual visibility calculations themselves should be quite fast. And only those parts of the map which actually change would need to be updated although it's doubtful if that would be faster than just DMAing the whole thing. It should be possible to just update the high byte of the tilemap, and make the tiles all black by changing the palette (reserving one palette for all black colors) - the high byte would need updating anyways because the tile should hide the sprites in the black areas meaning that the priority bit would have to be set.
I'd rather update the low byte of the tilemap if I had to choose between the 2. Reserve chars 0x000, 0x100, 0x200 and 0x300 to be black and you only lose 3 chars instead of 1 palette.

Updating the shadow can be done in less than 1 frame of calculation. From what I'm seeing on the video, the shadow map needs to be at least 11x7. Make it 16x8 during calculation where you use 1 bit per tile. That way, you can work an entire row of shadow at a time. Since the shadow can only move 8 directions, it can be done with just bitwise operations. If you keep a predetermined 1-bit shadow map (where the walls are), it's even faster because you don't need to test any bit and you can just spread it around immediately.

When applying the shadow map to your tiles, you can zero your buffer with DMA and only copy visible tiles. I'm sure comparing is faster than redoing the whole thing but I personally wouldn't bother with this unless I needed higher performance.

Calculating shadow (including uploading to VRAM) should take about 7000 cycles.
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: Porting Cyberdogs to Super Nintendo

Post by Oziphantom »

There is this is basically pascals, preports to have SNES support not sure how well though https://lemonspawn.com/turbo-rascal-syn ... but-begin/
Post Reply