Wolf3D-like bitmap graphics

qbradq

New Member
Sep 14, 2019
24
13
3
I thought of an interesting way to do bitmap graphics suitable for a Wolf 3D clone :)
wolftest.gif

This demo uses screen scaling to produce a 160x120x4bbp image. A 10x8 matrix of 16x16 pixel tiles is arranged on the screen so as to fill the image. The image is then rendered as 80 vertical slices, each two pixels (or one byte) wide. Although not shown here, the two-pixel wide slice can have two different color pixels.

The arrangement of the tiles within the map combined with VERA's increment register allows one 2x120-pixel column to be written in a single loop without address manipulation.

The demo currently includes double-buffering, however I have not synced the page flip to NMI so there is screen tearing.

Finally, I doubt that we'll see Wolf 3D running on this thing. Not without some compromises anyhow :) Right now it's getting around 60fps, and 15fps would be playable for this kind of machine. But right now it's not doing: ray-casting, wall sampling, wall scaling, object detection, object sampling, object scaling, and fish-eye correction. I.E. everything that's not pushing pixels to the screen. Even with a much smaller view window I doubt there will be a lot of CPU left for the game part of the game :)

Anyhow, full source for ASM6 included.
 

Attachments

  • Like
Reactions: MonstersGoBoom

qbradq

New Member
Sep 14, 2019
24
13
3
There is no texture on the wall like in Wolfenstein.
Thanks for the interest!

It's not doing anything other than pushing pixels onto the screen, meaning no texture sampling. Also I just realized the version I posted still depends on external files. I am still toying with this and am going to see if I can produce a ray casting engine just to see how well it goes :)
 
  • Like
Reactions: MonstersGoBoom
Sep 9, 2019
30
8
8
I thought of an interesting way to do bitmap graphics suitable for a Wolf 3D clone :)
View attachment 349

This demo uses screen scaling to produce a 160x120x4bbp image. A 10x8 matrix of 16x16 pixel tiles is arranged on the screen so as to fill the image. The image is then rendered as 80 vertical slices, each two pixels (or one byte) wide. Although not shown here, the two-pixel wide slice can have two different color pixels.

The arrangement of the tiles within the map combined with VERA's increment register allows one 2x120-pixel column to be written in a single loop without address manipulation.

The demo currently includes double-buffering, however I have not synced the page flip to NMI so there is screen tearing.

Finally, I doubt that we'll see Wolf 3D running on this thing. Not without some compromises anyhow :) Right now it's getting around 60fps, and 15fps would be playable for this kind of machine. But right now it's not doing: ray-casting, wall sampling, wall scaling, object detection, object sampling, object scaling, and fish-eye correction. I.E. everything that's not pushing pixels to the screen. Even with a much smaller view window I doubt there will be a lot of CPU left for the game part of the game :)

Anyhow, full source for ASM6 included.
Impressive start . Well played ;)
 

Brendan Kidwell

New Member
Sep 18, 2019
9
7
3
New York City
www.glump.net
This demo uses screen scaling to produce a 160x120x4bbp image. A 10x8 matrix of 16x16 pixel tiles is arranged on the screen so as to fill the image. The image is then rendered as 80 vertical slices, each two pixels (or one byte) wide. Although not shown here, the two-pixel wide slice can have two different color pixels.

The arrangement of the tiles within the map combined with VERA's increment register allows one 2x120-pixel column to be written in a single loop without address manipulation.
So let me see if I have this straight: Instead of using a full-screen bitmap mode, your tile arrangement allows you to vertically fill stripes of the frame in a way that meshes with how you compute the scene logically (one or two columns at a time)? This makes it easier to do the math on the CPU and push the computed result straight to the VRAM via IO ports, compared to using a full-screen bitmap mode?

More pixels in fewer CPU cycles?
 
  • Like
Reactions: qbradq

qbradq

New Member
Sep 14, 2019
24
13
3
So let me see if I have this straight: Instead of using a full-screen bitmap mode, your tile arrangement allows you to vertically fill stripes of the frame in a way that meshes with how you compute the scene logically (one or two columns at a time)? This makes it easier to do the math on the CPU and push the computed result straight to the VRAM via IO ports, compared to using a full-screen bitmap mode?

More pixels in fewer CPU cycles?
Yes, that's exactly right. However the 6502 is a very poor choice for a ray casting engine due to the divides and multiplies involved. I'm sure someone with more experience than me could produce a 6502-based ray caster that performs reasonably well. I just thought I'd demonstrate the technique I thought of :)
 

qbradq

New Member
Sep 14, 2019
24
13
3
I've given this a bit more love. I was working on vertical texture scaling when I realized that the 4bbp format will outright prevent proper horizontal scaling. Here's the screenshot just so I can show something more colorful. I might try this again with 8bpp.

In the image the render area was reduced to 128x64 so I could make a few multiples shifts, and to reduce the total number of rays needed and texture samples taken.
 

BruceMcF

Active Member
May 19, 2019
100
30
28
Yes, that's exactly right. However the 6502 is a very poor choice for a ray casting engine due to the divides and multiplies involved. ...
Yes, this is why the SNES has hardware multiply help for it's 65816 based processor.

There's hardware multiplies inside Vera, and if they are not using all of them, it seems like one could be allocated to a 16bit by 16bit to 32bit and 8bit by 32bit to 32bit hardware unsigned multiply registers.Other than that, plenty of room for sum of squares multiply tables or nybble by byte multiply tables in High RAM ... also 1/x binary fraction tables to do division with multiply.
 

qbradq

New Member
Sep 14, 2019
24
13
3
Yes, this is why the SNES has hardware multiply help for it's 65816 based processor.

There's hardware multiplies inside Vera, and if they are not using all of them, it seems like one could be allocated to a 16bit by 16bit to 32bit and 8bit by 32bit to 32bit hardware unsigned multiply registers.Other than that, plenty of room for sum of squares multiply tables or nybble by byte multiply tables in High RAM ... also 1/x binary fraction tables to do division with multiply.
These are exactly the kind of techniques I have never used :) Every time I've done one of these it was on a platform with hardware multiply and divide. A hardware multiply on a VERA register would be awesome!
 
  • Like
Reactions: BruceMcF