⚡ NEW: Forums/ Mazed - Full Gallery 2025

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)

maze3d_top_tiles.png (2 KB)

maze3d_top_tiles_sg.png (1.31 KB)

Maze3dSG.png (12.38 KB)

Maze3dProfile.png (28.86 KB)

Maze3dMapCode.png (17.47 KB)

Maze3dLines.png (11.83 KB)

Maze3dGG.png (11.36 KB)

Maze3dGB.png (10.19 KB)

Maze3dZX.png (14.9 KB)

Maze3d-1.01.zip (127.27 KB)

Awesome project, and awesome technical explanation.
Would there be any demo ROMs/source code/video recordings available?
Please, keep us updated. ;)

Yeah this is really great stuff, very impressive!

Oh my...very interested to see this developing!

I've attached Demo ROMS for your platform of choice.

Maze3d-1.01.zip (127.27 KB)

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 ;)

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 :)

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.

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):

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.

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.

I realise it's early days but this is awesome. Wolfenstein 3D running on Sega Master System. WOW!!

Hope it gets updated!

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.

Maze3d-SMS-1.01-edit.png (1.57 KB)

wolfenstein maze3d.png (3.46 KB)

wolfenstein maze3d less colors.png (3.18 KB)

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-7.png (2.97 KB)

Maze3dSMS-4.png (2.2 KB)

Maze3dSMS-8.png (4.31 KB)

Maze3d-SG-1.03.zip (17.13 KB)

Maze3d-SMS-1.03.zip (26.23 KB)

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.

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.

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)

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?

Thanks, selected the wrong file there.

Maze3d-SMS-1.04.zip (37.52 KB)

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.

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.

wolf3d_soldier_fire_x6.png (8.56 KB)

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.

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?)

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.

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.

DiamondDash2-GB-1.01.zip (37.75 KB)

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/

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)

Maze3d-GG-1.04.zip (31.1 KB)

Maze3d-GB-1.04.zip (26.21 KB)

I like the original PC sprites better. They might scale better, too.

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.

soldier_zoomed_178_slogra.png (2.51 KB)

Author	Message
under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	Maze3d 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 cols16 rows2b 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) maze3d_top_tiles.png (2 KB) maze3d_top_tiles_sg.png (1.31 KB) Maze3dSG.png (12.38 KB) Maze3dProfile.png (28.86 KB) Maze3dMapCode.png (17.47 KB) Maze3dLines.png (11.83 KB) Maze3dGG.png (11.36 KB) Maze3dGB.png (10.19 KB) Maze3dZX.png (14.9 KB) Maze3d-1.01.zip (127.27 KB)

haroldoop Joined: 25 Feb 2006 Posts: 970 Location: Belo Horizonte, MG, Brazil	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. ;)

willbritton Joined: 06 Mar 2022 Posts: 810 Location: London, UK	Posted: Sun Jun 12, 2022 6:19 pm
	Yeah this is really great stuff, very impressive!

S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Posted: Sun Jun 12, 2022 10:29 pm
S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Oh my...very interested to see this developing!

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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)

umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	Posted: Mon Jun 20, 2022 12:12 pm
umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	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 ;)

umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	Posted: Mon Jun 20, 2022 1:13 pm
umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	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 :)

willbritton Joined: 06 Mar 2022 Posts: 810 Location: London, UK	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.

umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	Posted: Mon Jun 20, 2022 1:52 pm
umbe1987 Joined: 03 Dec 2021 Posts: 126 Location: Italy	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):

willbritton Joined: 06 Mar 2022 Posts: 810 Location: London, UK	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.

sverx Joined: 05 Sep 2013 Posts: 4315 Location: Stockholm, Sweden	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.

8BitBoy Joined: 15 Aug 2019 Posts: 318 Location: Lancashire UK	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!!

S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Posted: Thu Jun 30, 2022 2:40 pm
S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Hope it gets updated!

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Thu Jun 30, 2022 5:42 pm
slogra Joined: 09 Jun 2014 Posts: 488	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. Maze3d-SMS-1.01-edit.png (1.57 KB) wolfenstein maze3d.png (3.46 KB) wolfenstein maze3d less colors.png (3.18 KB)

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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-7.png (2.97 KB) Maze3dSMS-4.png (2.2 KB) Maze3dSMS-8.png (4.31 KB) Maze3d-SG-1.03.zip (17.13 KB) Maze3d-SMS-1.03.zip (26.23 KB)

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Fri Jul 01, 2022 11:59 am
slogra Joined: 09 Jun 2014 Posts: 488	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.

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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.

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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)

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Tue Jul 19, 2022 9:23 am
slogra Joined: 09 Jun 2014 Posts: 488	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?

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	Posted: Tue Jul 19, 2022 10:30 pm
	Thanks, selected the wrong file there. Maze3d-SMS-1.04.zip (37.52 KB)

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Wed Jul 20, 2022 6:48 pm
slogra Joined: 09 Jun 2014 Posts: 488	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.

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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. wolf3d_soldier_fire_x6.png (8.56 KB)

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Thu Jul 21, 2022 9:39 am
slogra Joined: 09 Jun 2014 Posts: 488	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.

S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Posted: Thu Jul 21, 2022 2:19 pm
S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	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?)

Cavencruiser Joined: 03 Oct 2020 Posts: 14	Posted: Fri Jul 22, 2022 12:32 pm
Cavencruiser Joined: 03 Oct 2020 Posts: 14	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.

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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. DiamondDash2-GB-1.01.zip (37.75 KB)

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Sat Jul 23, 2022 3:10 am
slogra Joined: 09 Jun 2014 Posts: 488	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/

under4mhz Joined: 17 Jan 2020 Posts: 118 Location: Brisbane, AU	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) Maze3d-GG-1.04.zip (31.1 KB) Maze3d-GB-1.04.zip (26.21 KB)

S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	Posted: Fri Jul 29, 2022 7:29 pm
S.F Joined: 08 Apr 2005 Posts: 492 Location: Netherlands	I like the original PC sprites better. They might scale better, too.

slogra Joined: 09 Jun 2014 Posts: 488	Posted: Tue Aug 02, 2022 10:13 pm
slogra Joined: 09 Jun 2014 Posts: 488	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. soldier_zoomed_178_slogra.png (2.51 KB)

⚡ NEW: Forums/ Mazed - Full Gallery 2025

Forums

View topic - Maze3d