Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Maze3d

Reply to topic Goto page 1, 2  Next
Author Message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Maze3d
Post Posted: Sun Jun 12, 2022 2:33 am
Last edited by under4mhz on Sun Jun 12, 2022 10:33 pm; edited 2 times in total
After our discussion of 3D graphics, I thought I’d have a look at optimising my Mazenstein3d code.

I converted the graphics to use tiles instead of lines, added a lut for the line angle division, removed the doors being in between the walls, cached the tile data to upload to the vdu and moved to sdcc 4.2.

Now that it’s tile based, it was fairly easy to port the code to SMS and GG.

The improvements moved the frame rate from 3.5fps up to 7fps for SMS and 9fps for GG. The SG(-1000) is running at 6fps, since it has no memory for tile caching. The poor little GameBoy(GB) port is running at 5fps, but that’s a reflection of the GB only being able to write to the vdu during vsync, my vdu library being written in C. Interestingly the ZX spectrum version runs at the same speed as the SG (but I wrote a bucket load of assembler in the vdu library to get it that fast).

The engine only casts one ray per column (32 for SMS and 20 for GG) and the heights between two columns are averaged to get the angle. If a corner is detected, the averaging is disabled, since these walls need to be sharp up to the edge.

This is why the GG is significantly faster here, since it builds only 60% of the scene that the SMS version does. It’s possible to make the scene wider for GG, but it would still be only 20 columns wide.

All the divide and multiply functions are unrolled loops. One divide that was possible to remove (and replaced with a lookup table(LUT)) was the 1/player rotation angle calculation, since this is constant and only dependent on the player view rotation.

The sdcc compiler with its new feature of passing parameters in registers generally gives about a 10% speed improvement. The SMS version using sdcc 4.1 runs at a flat 6fps, whereas the 4.2 version runs about 7fps. The ZX and GB ports didn't work properly in sdcc 4.2, I'll have to look into that at some point. The screenshots for GB and ZX are for 4.1 and are 10% slower than the others.

The doors are a bit deeper into the walls than before. This is because to render the doors half way between the walls, the map position (x,y) was halved, so the doors could fit in between. A single unit on the map is a wall thickness, and drawing something in between is difficult. By making the doors aligned with the walls, half the ray casting looks up could be removed.

All the tile data is written to a 1024b array (32 cols*16 rows*2b per tile), being (slightly) faster to randomly access an array and blit the data to the vdu.

The map is a simple text map stored as strings. These were taken from screenshots of the original maps. A custom converts the 8x8 tiles on the image to text characters. There are a large amount of unique tiles on the maps, but these have been culled down to wall, space, door and starting point for speed and a lack of tile space.

The tiles are split between door and wall colours. A tile is stored for each angle between horizontal and diagonal, for each of the 8 possible pixel heights for a tile. Each different colour requires its own tile set.

The walls look a bit wonky, since only one tile is rendered for the top of the wall. This means a line that crosses between two vertical tiles, will only render one of them for the column. This is why some columns have a flat top or aren't as sloped as expected. It’s a trade-off between accuracy and speed, the more visually accurate it is, the slower it’ll go. The trade off here is worth it, since once the player starts moving, the small rendering inaccuracies are generally forgiven (as long as the game is fast and fun).

The graphics takes advantage of the (SMS’s) ability to flip the tiles vertically and use the sprite palette for tiles to make the floor tiles grey and the bottom row of tiles. It’s possible horizontal flip to remove half the wall tiles again to allow for more colours and possibly textures. The GameBoy doesn’t have this feature, and so runs out of tiles. Either the door will need to be rendered with edges of the wall colour, half the possible angles of the lines or make the doors the same colour as the walls. The ZX version run out of tiles as well, since only 256 tiles (1byte) are cached in the internal tile memory space that's been implemented. The SG version is blocky to allow border lines to be drawn on top of the walls. This gives better definition to the walls, and is worth the trade-off of the blocker look.

It is possible to add wall textures, but this will slow it down again. Each texture will have to be added during the wall rendering according to height, and each look up slowing it down. Right now, a single tile is used for the walls, which can be written quickly. The number of tiles would be large as well, requiring 32 tiles for each texture, one for each of the 32 possible angles, and that is if the same texture is used into the distance.

The great thing about demos is that we don’t have to worry about trivial details such as opponents and pickups. Which will slow the engine down significantly. So look at these results with that in mind.

Tile space is needed for each of these on the screen, for each zoom level. Each item on the screen will need its own set of tiles, each zoom level loaded as required. This will limit the number of objects on the screen at once.

There’s definitely some more gains to be had here. The function that does the searching for walls (ray casting) is all in C, which can be written in assembler for a double speed improvement. As can the code to write the scene to the cache.

Being a (pseudo) 3D engine, it’s one of the few games where nearly everything is an inner loop and could be re-written in assembler for a speed improvement. Basically, anything labelled “Self Time” in the profile graph below would likely be halved if written in assembler. That’s probably about a 20% improvement, so maybe another 2fps. I’m probably not going to do that. Z80 assembler is fun, but time consuming and unreadable after a week (though somehow incredibly clear at the time).

Adding enemies will probably take 1 or 2fps away, and if I rewrite the rendering and casting code in assembler, it may end up steady at about 6fps on an SMS.

Next, I’ll probably work on supporting making the rooms different colours. The doors will be marked as a colour and upon opening, the palette will be updated to reflect the rooms’s colour. Two sets of tiles can be used to flip between the current wall colour and the next, so the existing room will have the same colour walls.

I’ll also work on making it a complete game with all the levels (minus any enemies), so that it’s a complete game in its own right. That’ll at least make it a more interesting and playable game, even if it’s not a first person shooter.

I'll probably port it to Amstrad CPC 464 and Microbee as well, becausing porting stuff to other platforms is fun (and easy, after the first one).
Maze3dSMS.png (13.01 KB)
Maze3dSMS.png
Maze3dSG.png (12.38 KB)
Maze3dSG.png
Maze3dProfile.png (28.86 KB)
Maze3dProfile.png
Maze3dMapCode.png (17.47 KB)
Maze3dMapCode.png
Maze3dLines.png (11.83 KB)
Maze3dLines.png
Maze3dGG.png (11.36 KB)
Maze3dGG.png
Maze3dGB.png (10.19 KB)
Maze3dGB.png
Maze3dZX.png (14.9 KB)
Maze3dZX.png
Maze3d-1.01.zip (127.27 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 25 Feb 2006
  • Posts: 761
  • Location: Belo Horizonte, MG, Brazil
Reply with quote
Post Posted: Sun Jun 12, 2022 1:27 pm
Awesome project, and awesome technical explanation.
Would there be any demo ROMs/source code/video recordings available?
Please, keep us updated. ;)
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 216
  • Location: London, UK
Reply with quote
Post Posted: Sun Jun 12, 2022 6:19 pm
Yeah this is really great stuff, very impressive!
  View user's profile Send private message Visit poster's website
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Sun Jun 12, 2022 10:29 pm
Oh my...very interested to see this developing!
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sun Jun 12, 2022 11:47 pm
I've attached Demo ROMS for your platform of choice.
Maze3d-1.01.zip (127.27 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 03 Dec 2021
  • Posts: 42
Reply with quote
Post Posted: Mon Jun 20, 2022 12:12 pm
This already looks incredible, congrats and keep up the great work!

I am yet completely ignorant in programming for the SMS (although I am about to begin), so please forgive me if this does not make much sense.
I once saw a video of toy story the videogame for the genesis made by its main developer who explained that for the FPS part he basically draw only half of the screen (either bottom or top) and the rest was just mirrored, as the 3d scene was symmetric along the horizontal center line. Would the SMS be able to do that, or is it something that you already do/ are considering?

Again, sorry of this question does not make much sense, and keep up with the neat project ;)
  View user's profile Send private message
  • Joined: 03 Dec 2021
  • Posts: 42
Reply with quote
Post Posted: Mon Jun 20, 2022 1:13 pm
under4mhz wrote
The graphics takes advantage of the (SMS’s) ability to flip the tiles vertically and use the sprite palette for tiles to make the floor tiles grey and the bottom row of tiles.


Oh, I guess this means you are already doing it :)
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 216
  • Location: London, UK
Reply with quote
Post Posted: Mon Jun 20, 2022 1:31 pm
You can't mirror the whole screen down or across the middle, if that's what you mean (*)

(I was actually unaware of the mega drive / genesis being able to do that, and although there are a couple of great YouTube videos on fancy stuff in ToyStory, I couldn't find reference to that)

You can mirror individual 8x8 background tiles either horizontally, or vertically, or both at the same time, by setting bits 9 and 10 in the 16 bit entry for that tile in the screen map - that's what under4MHz is referring to here.

You can't mirror sprite tiles, so they will always always facing the same way. See this thread for an interesting discussion of the only alternative, which is to design a left-facing and right-facing tile (for horizontal scrolling games).

* Note, just thinking there are numerous mask bits in some of the VDP registers which might (?) allow repeating sections of the screen, although I can't think of how they would literally reflect portions of it.

UPDATE: yeah looks like from this guide you can clear bit 0 of register 2 which will have the effect of repeating the top 16 rows of the screen in the bottom 8 rows of the screen. Again, not reflected, just repeated.
  View user's profile Send private message Visit poster's website
  • Joined: 03 Dec 2021
  • Posts: 42
Reply with quote
Post Posted: Mon Jun 20, 2022 1:52 pm
Thank you for your feedback, really appreciate that :)

willbritton wrote

(I was actually unaware of the mega drive / genesis being able to do that, and although there are a couple of great YouTube videos on fancy stuff in ToyStory, I couldn't find reference to that)


I was referring to this video actually, even though I am totally unaware on how it works (about t=4:30 it talks about it):

  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 216
  • Location: London, UK
Reply with quote
Post Posted: Mon Jun 20, 2022 6:22 pm
Ah, okay, so actually what I think is happening here is that there's a fixed screen map and he's updating the tile definitions continuously.

Forgive me if you already know this stuff, but basically the SMS (and Megadrive I believe) has a screen map of 32x24 tiles. Each tile is 8x8 pixels. That means in the VRAM of the VDP there's a table of 768 entries each of which references a tile definition (aka patterns). There are space for 512 (ish...) patterns for the SMS.

For most games, like 2D-scrollers, there is a fixed set of tiles and the screen map simply determines where those tiles are placed on the screen. So for example, you might have the top 20 rows of 32 tiles be tile #1 which is plain blue - for the sky; and the bottom 4 rows of 32 tiles be tile #2 which is plain green - for the grass. This way you only need 2 background tiles to draw the whole screen. Those 2 tile never change, but what you can do is change the screen map so that different tiles are sky and different ones are grass. For example, to create the effect of a set of "steps" going up or down hill.

Alternatively, you could instead create a fixed screenmap, so it might look something like this:

1 2 3 4 5 6 7 8 9 10 11 12 .......... 32
33, 34, 35, 36, 37, 38, 39...........64
...
...
736, 737, 738, 739..........768


(that's assuming you can define 768 different tiles, which in the SMS you can't, but see below!)

This way, instead of changing the screen map in response to user action, you keep the screenmap fixed but change the tile definitions. e.g. if you change the definition for tile #1 it changes the top left 8x8 pixels of the screen, and if you change the definition for tile #32 it changes the top right 8x8 pixels of the screen.

This allows you to more finely control the actual pixels on screen without being limited to a fixed set of tiles. However it's significantly slower because (for the SMS) you need to update 4 bytes of data for each tile, instead of just 1 to modify a single tile reference in the screen map.

Now, in this Toy Story 3D example they are doing the fixed screen map technique, but they are storing a screen map which mirrors itself.

e.g. it looks like this:

1 2 3 4 5 6 7 8 9 10 11 12 .......... 32
33, 34, 35, 36, 37, 38, 39...........64
...
321, 322, 323, 324............352
353, 354, 355, 356............384 // this is halfway down the screen
353, 354, 355, 356............384
321, 322, 323, 324............352
...
33, 34, 35, 36, 37, 38, 39...........64
1 2 3 4 5 6 7 8 9 10 11 12 .......... 32


Crucially, when the screen reflects on rows 13 and above, the tiles are also flipped in the x-axis ("vertical flip")

This means that:

1. You now only need 384 tile definitions instead of 768- win!
2. The screen is automatically reflected in the x-axis, i.e. when you update tile #1 it updates both the top left 8x8 pixels in the screen and the bottom left 8x8 pixels in the screen.
3. It's half as many tiles needed to update - win win!

Now, is this technique possible on the SMS? In theory, yes. However in practice writing to VRAM on the SMS is significantly slower than in the Megadrive. How much slower I'll have to work out on the back of an enveloper, but the Megadrive support something called DMA which means the CPU can write directly to VRAM, whereas the SMS needs to "talk" to its VDP via a relatively slow interface which only allows a certain limited throughput of data. Will update with some more specifics when I get the chance but I think this would put the theoretical throughput too low for a reasonable 3D experience based on this technique.
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3262
  • Location: Torino, then London, now Stockholm
Reply with quote
Post Posted: Tue Jun 21, 2022 7:05 am
the only way to mirror the top half of the background is to reuse the same tiles vertically flipped and arranged bottom-up in the bottom part of the screen - yes, it takes time but fortunately you can write to the VDP even outside of vBlank, you just have to accept to do it slower.
  View user's profile Send private message Visit poster's website
  • Joined: 15 Aug 2019
  • Posts: 193
  • Location: Lancashire UK
Reply with quote
Post Posted: Thu Jun 30, 2022 1:44 pm
I realise it's early days but this is awesome. Wolfenstein 3D running on Sega Master System. WOW!!
  View user's profile Send private message Visit poster's website
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Thu Jun 30, 2022 2:40 pm
Hope it gets updated!
  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Thu Jun 30, 2022 5:42 pm
I like your Doomguy (Wolfensteinguy, Mazeguy?), especially considering the little number of colors you used.

I've created one with more colors, using colors in the palette that were not being used yet.
I've also included an alternative version with less colors but still more that yours.

  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Fri Jul 01, 2022 7:50 am
Awesome. That really looks fantastic. I've added it to this demo release. I'll animate him later.

Keep in mind that we need a few colours for the gun firing, and an extra colour to be able to swap wall colours as we move through the rooms.

I never realised what a challenge it was to create a good looking screen from only 16 colours, until I started having to do it. (GG: you have 4096 colours, but you can only use 16, argh!).

I've tried to clean up the rendering a bit and did some optimisations to bring it up to a whopping 8fps (~average). I've also added three more levels (a total of four), with a static screen at the end of the level. Only 4 since, that fits into 48K without having to deal with bank swapping yet.

I realigned the status bar to fit better with the tiles and reduced the screen height to 16 rows, faster and easier to show the weapon. The numbers on the status bar are actually rendered, instead of being a part of the status bar image.

I've also added a single static enemy to test the feasibility adding enemies, since the scaling requires loading all the tiles in vdu as required. Not sure how I'll deal with transparency for the soldier, sprites maybe? Though I'll need mixture of tiles and sprites when he's large, which will be a lot of work to implement.
Maze3dSMS-6.png (2.25 KB)
Maze3dSMS-6.png
Maze3dSMS-7.png (2.97 KB)
Maze3dSMS-7.png
Maze3dSMS-4.png (2.2 KB)
Maze3dSMS-4.png
Maze3dSMS-8.png (4.31 KB)
Maze3dSMS-8.png
Maze3d-SG-1.03.zip (17.13 KB)
Maze3d-SMS-1.03.zip (26.23 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Fri Jul 01, 2022 11:59 am
I haven't played it yet, but the screenshots look great.
I guess you can use 32 colors if you use background tiles only, and no sprites.
And how many colored walls do you want in one level? Just 2 like i the current version?
Perhaps an ingame color swap of the palette is possible to change wall colors of a different section. Although i think it will always cause a slight pauze.

If you use orange for fire then you can make doomguys hair orange.
The soldier has darkgreenbrown pants in your screenshot. So you could use that for another shade of brown of doomguy. Although simply dark red might look better instead.

Oh well, it's an awesome project, that look great already. The solution with all those different angled tiles is genious! I wish i was able make something like that.
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Fri Jul 01, 2022 11:11 pm
I'll probably want 3 colours for the walls and doors, one colour for the doors, one for the current room and one for the next room. I'll cycle through them as the player encounters a new room colour. I'll probably have a third copy of the tiles using a different palette colour so there should be no pause between rooms. Though this will take extra vdu space and so limit how many objects I can have in a room. I'll reduce the tiles used by using the horizontal flip feature, but this reduces the frame rate.

I've reused doomguy's current colours in the gun firing; I think it looks good enough, maybe a bit of red. I have a spare palette slot or two.

I'm currently using the tile palette for the background (walls and doors) and status bar, and the sprite palette for any of the objects (soldiers, food, treasure etc). Using a mixture of tile and sprite palettes in a single object would be possible, but that will much harder to implement.

Given the vdu size limitations, I'll probably have to limit the soldiers to one per room and only have one type of object per room (eg soldier or food). I need two copies of any object in the vdu at the same time - one for the current image and one for the next image (as you move closer, or he animates or moves). This is so I can load the image in background with out the change in tiles being seen by the player.

Thanks, I sat on this engine for a year trying to figure out use tiles instead of lines. Once I sat down and actually did it, it wasn't as difficult as it sounds.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Tue Jul 19, 2022 3:42 am
Last edited by under4mhz on Tue Jul 19, 2022 10:29 pm; edited 1 time in total
I've added the 10 levels from the first episode (not tested) and added all the enemies (as soldiers). At this point it's all the possible soldiers, so it's effectively on the hardest level. No interactions with the npc's yet. They're just there for show. I'll probably cull the npc's so there's only one on a screen at a time, since loading two at a time takes up too much vdu memory. It may be possible if they're far apart, since smaller images take up less vdu space. No collectables yet and you can walk through soldiers.

There's background music and basic sound effects for the weapon (since that was fairly easy to add).

The walls change colour according to the well texture, to give a sense of progress through the game.

With all the extra soldiers, it's slowed down to about 6fps. Loading soldier images slows it down to about 4fps. There's probably some gains to be had (ie less npc's, cache images) but there's still npc AI to implement, so it probably won't be much faster.
Maze3d-SG-1.04.zip (27.52 KB)
Maze3d-SMS-1.04.zip (37.52 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Tue Jul 19, 2022 9:23 am
i am unable to play it right now, but is sounds very nice! Can you upload the sms version too?

I was wondering how games like Altered Beast, Street Fighter and Golden Axe etc handle transparancy of background on background tiles. Would that work in your game or would it be too slow?
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Tue Jul 19, 2022 10:30 pm
Thanks, selected the wrong file there.
Maze3d-SMS-1.04.zip (37.52 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Wed Jul 20, 2022 6:48 pm
Sehr schön! You are making amazing progress!

Nice improvement of the soldier background.
I didn't expect the soundfx to be this spot-on! The music sounds great already. I don't know how you did that.
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Thu Jul 21, 2022 12:14 am
The music I took from some midi conversions of the original music I found. I already have code to convert midi to psg, so it was quite simple to add - as long as the midi is simple enough, with limited channels.

The sound effects I took from my Arno Dash engine. It just uses the white noise channel and reduces the volume over a second. It gives a nice "snap" impression that way.

Sound effects are going to be interesting. There's a PC speaker version of Wolfenstein https://www.youtube.com/watch?v=5v36e4_jars, but I think we can do slightly better than that with 3 channels and noise. I think the door open sound we can probably get closer to Adlib, using a few channels and noise at the same time. The original sound effects were all 8 bit digital playback we can of course have 4(ish) bit digital sound playback on the SMS, as long as we're willing to halt the game to do so. Which we're probably not.

The backgrounds are still static, I just changed the images so that walls start at their shoulders and stop at their boots. The green is so it's a unique colour from the blue of the status bar (making it the same colour caused the status bar to change colours when the wall did).

I'm thinking to use sprites, I should be able to fit a soldier into 32 8x16 sprites. Updating the tiles in place will be too slow. It already drops to 3fps just to load the images. While I find fixing these things is fun, these a graphical details I try to leave till last. It's better to have a working game with a few graphical glitches than a beautiful demo no one plays (if your goal is to write a playable game, of course).

I'm still not certain the fps of the game is going to be high enough. Each feature takes fps away, and at 6fps it already feels a bit sluggish.

I had my doubts about coding a violent game, but I guess we're all adults here, and writing 3D games is fun.

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Thu Jul 21, 2022 9:39 am
Where is the soldier image from? The original is actually smaller, right?
How about using zoomed sprite mode of the sms?
You should be able to save some tiles when using zoom mode.

Perhaps you can use a short door open sample. If you are not gonna use a door open animation, then only the sound and a (very) short pauze "might" be nice instead.
  View user's profile Send private message
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Thu Jul 21, 2022 2:19 pm
What's there already is quite amazing! Really looking forward to each update, since I'm a big fan of the original game.

Do you think it's possible to leave one of the tiles on the door as black (in the position of the handle?). Also the doors open up if you hold the open key and you're able to clip through. It's not possible to use the action key once to open them? (and they remain open for x seconds?)
  View user's profile Send private message Visit poster's website
  • Joined: 03 Oct 2020
  • Posts: 6
Reply with quote
Post Posted: Fri Jul 22, 2022 12:32 pm
What happened to the gb port of this? Will it be continued? I have tried the 1.1 rom on my everdrive and it didnt load, it seems the rom has no mapper settings applied and just hangs on the Ni****do logo.
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sat Jul 23, 2022 1:05 am
Last edited by under4mhz on Sat Jul 23, 2022 7:42 am; edited 3 times in total
The soldier images are from the high-res Mac version someone did: Mac HiRes. I didn’t realise that these were actually not the correct tiles to begin with, I just searched for tiles. It turned out quite well.

Using the sprite zoom mode is a good idea, since it will allow me to load less tiles, and possibly fit all the tiles into vdu at once. I'll have to see how it looks in practice.

It may be possible to add a door handle, if it’s just a single block. I may have to check how wide the door is and hide it if it’s too thin. I’ve contemplated adding simple textures (eg occasional vertical lines) along the walls to give the impression of bricks/panels without using too many tiles.

The way I’ve implemented doors at the moment is, on opening, all the doors open within a distance to the player. That’s why the door open time is so short; if you move too fast to the next door, you’ll see that it’s open as well. I should be able to do something smarter, like leave it open till the player has moved a certain distance. The reason for this is to make the code for the doors as simple (and quick) as possible.

Door animation may be possible, but at the moment the door is there or it isn’t; this made it easy to implement. Animating the door requires a further calculation of “where on the door has the ray hit” which is slightly complicated and slower. Something I’ll probably leave till the gameplay is more solid.

Gameboy is going to be a problem. It only has 256 tiles in total, and it doesn’t support tile flipping (in the original b/w version). Most of the 256 tiles are used just for the top of walls (which is why the bottom is blocky on the screenshot), let alone enemies and status bars. My plan at the moment is to complete it for the SG/SMS and see what level of features are possible to port to other platforms (given vdu and memory limitations). I haven’t implemented bank switching on Gameboy yet. I also need to reduce the possible wall angles by half. Just having 0,1,2,4 pixel difference angle tiles would probably be enough to look sensible. I may need to make the walls and doors the same colour to be able to fit enemies and status bars.

Maze3d GB 1.1 works on mgba and Emulicious, but I don't have real hardware to test it on. Could you elaborate on the mapper settings? How can I check if they’re applied? v1.1 fits into 32K and doesn’t use a rom mapper. Maybe it’s an everdrive problem. Would you mind running the attached game and seeing if it works for you?

Edit: I found the problem with the Gameboy port, the header checksum was set to 0. I was able to replicate the problem with mame or Emulicious using the original boot rom. Thanks for letting me know.

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Sat Jul 23, 2022 3:10 am
The original soldier is twice as small, so if you use the zoom mode it will the same size as what you have now.
The original soldier looks a bit different though. Especially his helmet and shoes.
I wonder how many soldiers will fit on screen when using sprites.


You can find the original sprites at the usual place:
https://www.spriters-resource.com/pc_computer/wolfenstein3d/sheet/27851/
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Thu Jul 28, 2022 10:44 pm
I've updated the GameGear and Gameboy ports. The soldier's positions are a bit off. I haven't looked into why, but I think it's because of the way I'm handling the smaller screen widths.

The Gameboy port is a bit slower. I think it's because I'm waiting for the vblank inline rather than triggering the render on an interrupt.

I was thinking about using the sprite zoom feature. The problem will be the detail will drop between 3x and 4x. If you look at the image, you can see that 4 is less details than 3. Perhaps I can have a pretend 4 that loads all the tiles, but looks blocky, but that reduces some of the advantage of using zoomed sprites.
soldier_zoomed.png (2.53 KB)
soldier_zoomed.png
Maze3d-GG-1.04.zip (31.1 KB)
Maze3d-GB-1.04.zip (26.21 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Fri Jul 29, 2022 7:29 pm
I like the original PC sprites better. They might scale better, too.
  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Tue Aug 02, 2022 10:13 pm
under4mhz wrote

I was thinking about using the sprite zoom feature. The problem will be the detail will drop between 3x and 4x. If you look at the image, you can see that 4 is less details than 3. Perhaps I can have a pretend 4 that loads all the tiles, but looks blocky, but that reduces some of the advantage of using zoomed sprites.


I'm not entirely sure what you mean.

Using zoomed sprites will solve the transparent problem, so imho it's worth trying.
Yes, frames will look blocky, but so does the zoomed soldier in the original game.

The zoomed frame 3 might be the biggest problem. I'm not sure how it will look while playing.

I guess you will run into the sprite limit soon when you do not use zoom for frame 3.
But if you can use 32x64 sprites for frame 3, then i suggest to upscale the original graphics with Xbrz (or whatever scaler works best). Then scale down to the desired size.
Or perhaps someone has already upscaled the original graphics in a more faithful way.

You will still save a lot of tiles even if you just use zoom on frame 4, and not on 3.

  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sat Aug 13, 2022 1:56 am
I'm looking at using sprites, the problem is that zoomed sprites won't work on the MegaDrive. That seems to a fairly common way of playing SMS games now, so I'm not sure I want to exclude these users.

I only considered this might be a problem when I came across this video when googling myself, as one does:



I'm running out of sprites space for the largest guard zoom level, so I may have to fiddle my video memory to fit a bit more in (or use zoomed sprites).

I'm using ImageMagik with a point filter (which is no filter) to scale the images. The original game didn't have great scaling, so it keeps the feel the same. If I end up using zoom sprites, the image quality can't suddenly drop at the largest zoom level.

I've gone back to the original game sprites, to give a closer feel to the original.

Next is to have the guards draw, fire and injure us; they will still be stationary.
Maze3d-SMS.png (17.88 KB)
Maze3d-SMS.png
Maze3d-SMS-1.png (18.26 KB)
Maze3d-SMS-1.png
Maze3d-SMS-1.05.zip (37.33 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Sat Aug 13, 2022 5:18 am
It's looking great!

I'm not using a megadrive everdrive, so it did not cross my mind either.

Tough call. Zoom was a big advantage of sprites.
Another advantage of sprites is smooth movement.
And of course transparency.

But it should be possible the make the transparency work with background tiles as well (like in Altered Beast and Golden Axe).
Possibly even multiple overlapping background tiles.
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Tue Sep 06, 2022 4:41 am
I've updated so it's now a vaguely playable game. Still very much a demo.

All the collectable objects are implemented. You can collect jewels etc. Points are added for valuable items. The SG-1000 can only store 60 objects due to it's 1K, so the objects are heavily culled for that platform.

You can now shoot and kill guards and they animate when they're hit. You can be shot, but only 1 health each time. Guards only shoot when visible to the player. This avoids any line of sight calculation from the guard. The guards are stationary. All enemies are shown as guards and take one hit to kill.

Sprites are at a premium, so only one sprite is shown at a time. The closest guard, then the closest object. It would be possible to show more objects when they are all further away, but this requires the sprite space to be managed depending on the sizes of the objects. For now you'll see objects appear and disappear since there are multiple in the scene, but only one is shown. Palette size is also a limitation, since all the objects combined use over 16 colours.

The end of level screen is updated with the correct stats. The par value is always 1:50, I'll have to go look at the original to see the what the actual values are.

I fixed the door, so they stay open and then close when the player moves 3 spaces. This allows me to keep the simple logic of ignore all doors that close to the player when open.

So there's some feedback when shot, the red channel of the palette is or'd with 1 to make it flash red.

There's a bit of an accuracy issue with shooting I have to look into. It seems to favour one side over the other. Since it's quite jumpy, I want to make the shooting range fairly forgiving. There's also an alignment issue with the objects where they're sometimes in the wall.

It may be possible to optimise it for speed more, but probably only 1fps or so. As an aside, it's possible to do a full rotation in 4s on the original, and that's what I've used as a reference for the fps vs rotation trade off. The first long corridor (behind the door) takes 4s as well on the original.

Below is my todo list, in no particular order.

- Enemy moving logic
- Enemy shoots only if visible
- Damage based on distance (player and enemy)
- Object/wall alignment
- Lose a life
- Keys
- Multiple objects on screen (when small)
- Animate level end numbers
- Animate/update player status image
- Stay red on hit (reloads palette when animating)
- Wall rendering glitches
- Remove knife on collect ammo
- Knife when close only
- Rifle/Machine gun implement
- Aim accuracy/offset
- Key press in interrupt
- Dog/Officer/SS sprites
- Sound effects
- Optimise speed (rendering)
- Zoom sprites SG/GB
- Straifing
- End Boss
- Collect items only on move
- Select objects in places with no other sprites (skeleton, lights, armour)
- GG/Microbee/Colecovision/MSX ports
- GB sprite flickering
- GB objects misaligned
- GB show weapon
Maze3dSMS-24.png (2.32 KB)
Maze3dSMS-24.png
Maze3dSMS-20.png (2.49 KB)
Maze3dSMS-20.png
Maze3dSMS-19.png (2.05 KB)
Maze3dSMS-19.png
Maze3d-SMS-1.06.zip (68.02 KB)
Maze3d-SG-1.06.zip (50.88 KB)
Maze3d-GB-1.06.zip (49.21 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Wed Sep 07, 2022 8:43 am
Great progress! It is really coming together nicely, and plays very much like a game already.

1 sprite on the screen is a unfortunate limitation, but understandable. It's very cool that you change the palette for each sprite.
  View user's profile Send private message
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Fri Sep 09, 2022 10:47 am
Great to see an update. Very impressive improvements!

I was wondering, would the extra 64Kb chip used in Ernie Els on the Game Gear help speeding things up?
  View user's profile Send private message Visit poster's website
  • Joined: 30 Mar 2019
  • Posts: 8
Reply with quote
Post Posted: Fri Sep 09, 2022 9:19 pm
under4mhz wrote
I've updated so it's now a vaguely playable game. Still very much a demo.

All the collectable objects are implemented. You can collect jewels etc. Points are added for valuable items. The SG-1000 can only store 60 objects due to it's 1K, so the objects are heavily culled for that platform.

You can now shoot and kill guards and they animate when they're hit. You can be shot, but only 1 health each time. Guards only shoot when visible to the player. This avoids any line of sight calculation from the guard. The guards are stationary. All enemies are shown as guards and take one hit to kill.

Sprites are at a premium, so only one sprite is shown at a time. The closest guard, then the closest object. It would be possible to show more objects when they are all further away, but this requires the sprite space to be managed depending on the sizes of the objects. For now you'll see objects appear and disappear since there are multiple in the scene, but only one is shown. Palette size is also a limitation, since all the objects combined use over 16 colours.

The end of level screen is updated with the correct stats. The par value is always 1:50, I'll have to go look at the original to see the what the actual values are.

I fixed the door, so they stay open and then close when the player moves 3 spaces. This allows me to keep the simple logic of ignore all doors that close to the player when open.

So there's some feedback when shot, the red channel of the palette is or'd with 1 to make it flash red.

There's a bit of an accuracy issue with shooting I have to look into. It seems to favour one side over the other. Since it's quite jumpy, I want to make the shooting range fairly forgiving. There's also an alignment issue with the objects where they're sometimes in the wall.

It may be possible to optimise it for speed more, but probably only 1fps or so. As an aside, it's possible to do a full rotation in 4s on the original, and that's what I've used as a reference for the fps vs rotation trade off. The first long corridor (behind the door) takes 4s as well on the original.

Below is my todo list, in no particular order.

- Enemy moving logic
- Enemy shoots only if visible
- Damage based on distance (player and enemy)
- Object/wall alignment
- Lose a life
- Keys
- Multiple objects on screen (when small)
- Animate level end numbers
- Animate/update player status image
- Stay red on hit (reloads palette when animating)
- Wall rendering glitches
- Remove knife on collect ammo
- Knife when close only
- Rifle/Machine gun implement
- Aim accuracy/offset
- Key press in interrupt
- Dog/Officer/SS sprites
- Sound effects
- Optimise speed (rendering)
- Zoom sprites SG/GB
- Straifing
- End Boss
- Collect items only on move
- Select objects in places with no other sprites (skeleton, lights, armour)
- GG/Microbee/Colecovision/MSX ports
- GB sprite flickering
- GB objects misaligned
- GB show weapon

This...This makes me so, so happy I could cry. Not only have you pulled off such an impressive Master System port, but you've gone a step beyond and done the SG-1000 as well - knowing you'll be doing the Colecovision has sent me into giddy excitement, since the Coleco is one of my favourite consoles and seeing it finally get an amazing FPS shooter like this is just...AHHHH!

It's funny how it seems like the SG-1000 port runs somewhat faster than the SMS version, though that could be just me. I pray that this project sees it all the way through, because I've been wishing for something like this for YEARS!
  View user's profile Send private message
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sat Sep 10, 2022 3:11 am
I'm adding multiple object per screen at the moment. It basically requires creating a mini-memory manager to implement vdu memory handling. For example, 8 distance sprites can fit at once, only one guard if he's at full size, or mixture depending on the sprite size and number of tiles it needs.

I'm not using any caching at the moment. It would make uploading the sprites faster, but I would only need 2K for the larger sprites and the existing memory is enough. Then I can decompress to memory and upload to vdu. Optimisation I'll do last, once the game is working. I don't want to optimise code that I may throw away later.

The time is split fairly evenly between rendering the objects, rendering the walls and doing the raycasting. Most of the time in the wall rendering is in interpolating the walls, determining corners and edges and calculating which tiles to use. Times 32 columns. The time in the enemy rendering is split between determining the size and location of the objects and managing the vdu usage.

The SG-1000 is indeed faster. I tend to think of it as being less capable, but it has the same CPU as the Master System. Since it's graphics use less memory (being bit-based) the rendering is significantly faster. The tile table in the SG-1000 is half the bytes than the SMS (being 1 vs 2 bytes per tile), this makes it much faster to render to. Comparing the size of the roms, the SG is 100K where the SMS is 130K, it's another 30% of data to push around.

My main platform is SG-1000, since I had one as a kid, but I support Sega Master System by popular demand. I have a hardware layer in my vdu libraries for linux with lets me run the SG-1000 port natively linux and use gdb for debugging and printf to the terminal.

The Coleco port is broken at the moment, it should be easy enough to fix. I haven't added all the calls to manually disable the vdu interrupt, since it's on the nmi.

I wrote a script to convert the map file to something more readable, so I can manage the banks better. I've attached the output for anyone interested.
Maze3d-profile.png (57.39 KB)
Maze3d-profile.png
Maze3dSMS-map.txt (10.43 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 15 Aug 2019
  • Posts: 193
  • Location: Lancashire UK
Reply with quote
Post Posted: Mon Sep 12, 2022 11:50 am
Just a quick note to say I think the work you're doing on this is brilliant mate. I watched Revo play this on his YT channel last week and you've made so many improvements so quickly. Really impressive, well done.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sat Sep 24, 2022 4:09 am
Attached is the latest version.

Below is a list of added features:

- Multiple objects on screen at once (when small)
- Strafing
- Damage based on distance (player and enemy)
- Animate/update player status image
- Lose a life
- Sprites jumping horizontally when moving closer
- Fire missed when straight on
- Dog/Officer/SS enemies
- Rifle/Machine gun implemented
- Door Keys
- Minor speed optimisations

The list of remaining features:

- Enemy moves towards player
- Enemy fires when can see player (but not visible to player)
- Enemy blocks player
- End boss
- Win game screen
- Sound effects
- End level bonus
- Minor sprite and wall rendering issues

The end level boss is 8 tiles wide at 3x scale (scale is from 1-6), so I'll probably limit him to that size. Besides, you won't last very long getting closer anyway.

At the moment the enemies only fire at the player if they are on the screen. I'll have to cast a ray between the player and enemy to see if the enemy can see the player. The enemies don't block the player movement, so you can run right through them, which makes it easy to ignore them. The enemies are also stationary, which makes dogs rather pointless. All the enemies for this episode are implemented.

I rewrote the wall rendering so it breaks the scene into segments, where a segment is a straight line between two corners. This removes a lot of the checks for each column I had (is it a door, a corner, did it change colour). It now renders a line between each segment which is slightly faster (instead of averaging between two rays). If you see the walls jumping sometimes, that's because it's harder to detect a corner than you might think.

I've added strafing and you can lose a life. I've added the animation for the player status image.

It takes multiple hits to defeat the enemies based on their points and your distance. The enemy hit will also increases the closer the player is.

As many sprites are rendered on the screen as the sprite overflow and vdu space allows. I've only 128 tiles available for sprites (the rest is used for the tile tables) so only one guard sprite can be shown at full size, which takes about the full 8 sprites and 64 tiles (the other 64 are used to load the next frame without flickering).

And sound effects. The least exciting part of any game project (in my view). I've got the shooting, but the rest of them are as important.

Thanks for the kudos, I appreciated it.

I'd like to hear your thoughts and ideas. It gives me new ideas on how to improve it.
Maze3dSMS-26.png (2.41 KB)
Maze3dSMS-26.png
Maze3dSMS-27.png (2.52 KB)
Maze3dSMS-27.png
Maze3d-SMS-1.07.zip (132.42 KB)
Maze3d-SG-1.07.zip (91.77 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 08 Apr 2005
  • Posts: 438
  • Location: Netherlands
Reply with quote
Post Posted: Sat Sep 24, 2022 10:01 pm
Amazing progress again! It would be fun to build an SMS specific episode.
  View user's profile Send private message Visit poster's website
  • Joined: 30 Mar 2019
  • Posts: 8
Reply with quote
Post Posted: Sat Sep 24, 2022 10:06 pm
under4mhz wrote
Attached is the latest version.

Below is a list of added features:

- Multiple objects on screen at once (when small)
- Strafing
- Damage based on distance (player and enemy)
- Animate/update player status image
- Lose a life
- Sprites jumping horizontally when moving closer
- Fire missed when straight on
- Dog/Officer/SS enemies
- Rifle/Machine gun implemented
- Door Keys
- Minor speed optimisations

The list of remaining features:

- Enemy moves towards player
- Enemy fires when can see player (but not visible to player)
- Enemy blocks player
- End boss
- Win game screen
- Sound effects
- End level bonus
- Minor sprite and wall rendering issues

The end level boss is 8 tiles wide at 3x scale (scale is from 1-6), so I'll probably limit him to that size. Besides, you won't last very long getting closer anyway.

At the moment the enemies only fire at the player if they are on the screen. I'll have to cast a ray between the player and enemy to see if the enemy can see the player. The enemies don't block the player movement, so you can run right through them, which makes it easy to ignore them. The enemies are also stationary, which makes dogs rather pointless. All the enemies for this episode are implemented.

I rewrote the wall rendering so it breaks the scene into segments, where a segment is a straight line between two corners. This removes a lot of the checks for each column I had (is it a door, a corner, did it change colour). It now renders a line between each segment which is slightly faster (instead of averaging between two rays). If you see the walls jumping sometimes, that's because it's harder to detect a corner than you might think.

I've added strafing and you can lose a life. I've added the animation for the player status image.

It takes multiple hits to defeat the enemies based on their points and your distance. The enemy hit will also increases the closer the player is.

As many sprites are rendered on the screen as the sprite overflow and vdu space allows. I've only 128 tiles available for sprites (the rest is used for the tile tables) so only one guard sprite can be shown at full size, which takes about the full 8 sprites and 64 tiles (the other 64 are used to load the next frame without flickering).

And sound effects. The least exciting part of any game project (in my view). I've got the shooting, but the rest of them are as important.

Thanks for the kudos, I appreciated it.

I'd like to hear your thoughts and ideas. It gives me new ideas on how to improve it.

AAAAA Happy to see a new version! Wonderful job!
However, I don't know if this is a bug or not, but I can't seem to get past the Title Screen in both versions - no matter what I do, it just doesn't accept any input; I've tested other roms and they accept my input, so it must be a bug with this build
Edit: Turns out RetroArch has compatibility issues, I think? It works in EmuHawk! Will give feedback whenever I can!

Also, a little suggestion: Why not make a Development Discord Server? I think we'd be able to get updates and feedback even faster! Though that's my personal thoughts. Onto the reports!

Report 1: Okay, so far, I've noticed a few bugs - if there's an enemy around a corner, then half of their sprite will appear on the opposite end of the screen

Report 2: Tapping the Rifle/Machine Gun at a far distance will never kill, forcing you to get up close to shoot them

Report 3: You can't seem to open a door with a Rifle/Machine Gun without firing

Report 4: Many enemies (especially the SS) will fire INSTANTLY upon coming into view, giving you no reaction time to make the first move. This basically forces you to start firing blindly as you head down long hallways (This wouldn't be a problem if their alert sound was implemented or a visual indicator was given that a guard was alerted)

Report 5: After dying many times, I've realised your starting ammo is WAY too low, I frequently end up running out of ammo trying to pick off a single guard and end up having to try and use the knife

Report 6: Dogs drop ammo upon death (Not that I'm complaining, mind you since I need all the ammo I can get, but I figured I'd point it out lol)
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Sun Sep 25, 2022 7:13 am
Wonderful!

What core did you use in Retroarch?
I tested Retroarch 1.9.0 with Genesis Plus GX 1.7.4 core and it works fine.
  View user's profile Send private message
  • Joined: 03 Oct 2020
  • Posts: 6
Reply with quote
Post Posted: Sun Sep 25, 2022 3:42 pm
under4mhz wrote
Attached is the latest version.

Below is a list of added features:

- Multiple objects on screen at once (when small)
- Strafing
- Damage based on distance (player and enemy)
- Animate/update player status image
- Lose a life
- Sprites jumping horizontally when moving closer
- Fire missed when straight on
- Dog/Officer/SS enemies
- Rifle/Machine gun implemented
- Door Keys
- Minor speed optimisations

The list of remaining features:

- Enemy moves towards player
- Enemy fires when can see player (but not visible to player)
- Enemy blocks player
- End boss
- Win game screen
- Sound effects
- End level bonus
- Minor sprite and wall rendering issues

The end level boss is 8 tiles wide at 3x scale (scale is from 1-6), so I'll probably limit him to that size. Besides, you won't last very long getting closer anyway.

At the moment the enemies only fire at the player if they are on the screen. I'll have to cast a ray between the player and enemy to see if the enemy can see the player. The enemies don't block the player movement, so you can run right through them, which makes it easy to ignore them. The enemies are also stationary, which makes dogs rather pointless. All the enemies for this episode are implemented.

I rewrote the wall rendering so it breaks the scene into segments, where a segment is a straight line between two corners. This removes a lot of the checks for each column I had (is it a door, a corner, did it change colour). It now renders a line between each segment which is slightly faster (instead of averaging between two rays). If you see the walls jumping sometimes, that's because it's harder to detect a corner than you might think.

I've added strafing and you can lose a life. I've added the animation for the player status image.

It takes multiple hits to defeat the enemies based on their points and your distance. The enemy hit will also increases the closer the player is.

As many sprites are rendered on the screen as the sprite overflow and vdu space allows. I've only 128 tiles available for sprites (the rest is used for the tile tables) so only one guard sprite can be shown at full size, which takes about the full 8 sprites and 64 tiles (the other 64 are used to load the next frame without flickering).

And sound effects. The least exciting part of any game project (in my view). I've got the shooting, but the rest of them are as important.

Thanks for the kudos, I appreciated it.

I'd like to hear your thoughts and ideas. It gives me new ideas on how to improve it.



What about the gameboy version?
  View user's profile Send private message
  • Joined: 22 Mar 2015
  • Posts: 223
Reply with quote
Post Posted: Mon Oct 03, 2022 3:38 pm
This game is aMAZEing!, just played last update and I wondered what does the number bottom right mean? and notice it goes up when I overclock the emulator, it is related to framespersecond maybe, besides overclocking accelerates the game, so how about instead of accelerating the game improve the fps when overclocking the system, I've tried Genesis Plus GX up to 200%, is that possible in real hardware and beyond 200% without burning it down.

So my point is when a system is overclocked instead of accelerating the gameplay, improve the performance as today modern consoles does playing the same game from a standard to a pro counterpart.
  View user's profile Send private message
  • Joined: 29 Mar 2012
  • Posts: 774
  • Location: Spain
Reply with quote
Post Posted: Mon Oct 03, 2022 4:43 pm
I think this is fairly dificult in an old console as Master System. You should start working with delta times, so it'll be a madness...
  View user's profile Send private message
  • Joined: 15 Aug 2019
  • Posts: 193
  • Location: Lancashire UK
Reply with quote
Post Posted: Tue Oct 04, 2022 9:31 am
Do we or does anyone have any cover art for this one yet for Master System? I want to do a little YouTube video on this to get more coverage but would ideally like a box sleeve to use. Does anyone have a mock up yet? I found one for the Mega Drive already but want a Master System one now.

Thanks, Oli
Wolf3DMDa.png (1.99 MB)
Wolf3DMDa.png

  View user's profile Send private message Visit poster's website
  • Joined: 17 Jan 2020
  • Posts: 98
  • Location: Brisbane, AU
Reply with quote
Post Posted: Sun Oct 09, 2022 4:37 am
This version fixes some of the bugs and adds a few minor features.

The door open button is now the B button. This saves me writing extra logic around not firing the gun when opening a door.

The chance of hitting a guard at all at a distance was set to 1/4. The guard will now always be hit at a distance, with the greater distance causing less damage. I increased the restart ammo to 14 from 7.

The dog no longer drops ammo. Not sure where he was keeping it.

The enemies now move towards the player when alerted. This makes having the dogs sensible. The soldiers won't fire unless on the screen, or at point blank range. This saves me having a ray cast from the enemy to the player, to check if he's behind a wall. I may do that later.

When the enemy comes into view the enemy state will restart to running towards the player. Before the state was cycling between running and shooting, even if out of view.

The enemy should now be clipped when one the edge of the screen instead of wrapping around.

Enemies now block movement, so you can't just run through them.

I've added some place holders for sound until I do some sound effect development. For now I've used waon to convert the original adlib sound effects to midi then to psg. Many of them will be changed to use the periodic noise channel, such as the door open, and collect ammo and food.

The Gameboy port is working. I was going over the 4K boundary in the first rom slot, so I had to massage that a bit. It still has a view visual glitches I'll fix later. Each port tends to take a few days to get going, so I tend to leave the ports till last.

Now you can win the game (in theory). It comes up with the "you win" screen once you get to the end of the 9th level, though the stats are wrong. Hans is shown and works for SMS. For SMS he's limited to 3x scale to fit, but I doubt you'll be able to get closer anyway. For SG and GB he crashes because he's too wide. I'll probably have to use zoom sprites to show him on those two systems.

The SS and officers are slightly larger and are too large to fit in the vdu at the largest zoom, so I'll have to reduce the size of these to the same as the guards so they'll show on the screen without missing parts.

I've limited the game to 10hz. If I were to account for overclocked systems, it would be to make the movement steps and rotation finer. I suspect the majority of users don't have an overclocked system though, so I probably won't. Most emulators on turbo will speed up the vdu clock rate as well, not just the cpu, so I can't account for it.

The little number is frame rate x 10 (based on 60hz). I use that to tell me if my speed optimisations actually work. Obviously frame rate is rather critical, since it's pushing the system hard.

Next is fixing some graphical glitches and sound, adding some niceties such as animating the end level screen and adding bonuses. Possibly some speed optimisations. Making sure it's playable and the difficulty is reasonable.
Maze3dSMS-36.png (2.43 KB)
Maze3dSMS-36.png
Maze3dSMS-33.png (2.49 KB)
Maze3dSMS-33.png
Maze3dSMS-28.png (2.77 KB)
Maze3dSMS-28.png
Maze3dSMS-29.png (2.34 KB)
Maze3dSMS-29.png
Maze3d-SMS-1.08.zip (132.37 KB)
Maze3d-SG-1.08.zip (96.36 KB)
Maze3d-GB-1.08.zip (94.75 KB)

  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 715
Reply with quote
Post Posted: Sun Oct 09, 2022 6:33 am
under4mhz wrote
I've added some place holders for sound until I do some sound effect development. For now I've used waon to convert the original adlib sound effects to midi then to psg.


I didn’t know WaoN, but it seems interesting. Might be worth experimenting with.

If I want to convert sfx for the SMS, I usually use furrtek's PSGtalk to convert a .wav to PSG at 60 Hz, then clean up the result in Mod2PSG2 or a similar tracker. That doesn’t work with the noise channel, though, and I’m not sure it’s actually easier than your method.
  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Sun Oct 09, 2022 10:55 am
Incredible progress again!

I've played around with the level end animation colors. The contrast is a bit higher so more details are preserved. It's not perfect, but perhaps you like it.

The same can be done with the font.

Edit: added 2 other versions with different greys.

  View user's profile Send private message
  • Joined: 09 Jun 2014
  • Posts: 270
Reply with quote
Post Posted: Sun Oct 09, 2022 2:20 pm
Last edited by slogra on Mon Oct 10, 2022 9:10 am; edited 1 time in total
I also worked on the title screen. Basically i separated some elements of the image: The wall, the doors, Doomguy, the soldier and de soldier's shadow.

Then recolored them each. Also I applied automatic dithering to the wall. And dithered the doors manually.

Unfortunately the combined result uses 23 colors. It would be cool if you could use the double palette background mode, to keep all 23 colors.

If not, then you can use the 16 color version. I used the same color on the lamp as the doors. Unfortunately i also had to change the golden brown in Doomguy's face to grey.


I did not do much manual editing (except for the dithering in the door), so there is still room for improvement. If you are good in manual editing :)


Edit: added some wall variations. 24 color versions with an extra color blue. And different dither types.
I removed the 23 color versions as the 24 color versions are better.

  View user's profile Send private message
Reply to topic Goto page 1, 2  Next



Back to the top of this page

Back to SMS Power!