16K 3D engine

[xxl]

4 hours ago, Heaven/TQA said:

XXL… can you share the source? I am curious.

 

The code is a terrible mess so far, I'm testing different concepts....
it's not worth it yet

there are at least a few other raycasting projects....

 

 

Edited February 19, 2022 by xxl

[xxl]

I added speedcode as a test - is there any visible difference because it requires 5KB of copy code.

 

 

[Heaven/TQA]

16 hours ago, xxl said:

 

The code is a terrible mess so far, I'm testing different concepts....
it's not worth it yet

there are at least a few other raycasting projects....

 

 

Yeah eg my own ?

[Heaven/TQA]

2 hours ago, xxl said:

I added speedcode as a test - is there any visible difference because it requires 5KB of copy code.

 

 

Unrolled code for what?

[emkay]

3 hours ago, xxl said:

I added speedcode as a test - is there any visible difference because it requires 5KB of copy code.

 

 

There is less visible "wobbling" . 

[xxl]

speedcode for copying from the buffer to the screen and instead of indexed absolute addressing I gave absolute - one cycle per byte which gives over a 1000 cycles of savings per screen - divide it by 2 or maybe even 3 and you get some ridiculous savings at the cost of additional 5 KB ... it doesn't seem reasonable to me.

 

Something worth looking into is optimizing the conversion of a column in the texture byte to a column in the screen byte - this is where you lose the most because you have to:
1. calculate the texture column
2. move it
3. determine AND for the screen column
of which only number 2 is repeated in the loop - maybe there is some savings

 

[Heaven/TQA]

22 hours ago, xxl said:

speedcode for copying from the buffer to the screen and instead of indexed absolute addressing I gave absolute - one cycle per byte which gives over a 1000 cycles of savings per screen - divide it by 2 or maybe even 3 and you get some ridiculous savings at the cost of additional 5 KB ... it doesn't seem reasonable to me.

 

Something worth looking into is optimizing the conversion of a column in the texture byte to a column in the screen byte - this is where you lose the most because you have to:
1. calculate the texture column
2. move it
3. determine AND for the screen column
of which only number 2 is repeated in the loop - maybe there is some savings

 

is it possible to enable 4 color mode and have a 4 col texture just to have a look? just to compare it with Alternate Reality: The Dungeon  

and record a video.

[xxl]

1 hour ago, Heaven/TQA said:

is it possible to enable 4 color mode and have a 4 col texture just to have a look? just to compare it with Alternate Reality: The Dungeon  

and record a video.

 

[Heaven/TQA]

17 hours ago, xxl said:

 

great stuff.

[xxl]

Unfortunately, I don't think so. After turning on the colors, I noticed errors in the graphics - I'll have to fix that (crossing the border in the wall width calculation). Also, I am very annoyed by the thickness of the walls. Does any of the raycasting engines on the A8 have thin walls implemented?

Edited February 22, 2022 by xxl

[Heaven/TQA]

4 hours ago, xxl said:

Unfortunately, I don't think so. After turning on the colors, I noticed errors in the graphics - I'll have to fix that (crossing the border in the wall width calculation). Also, I am very annoyed by the thickness of the walls. Does any of the raycasting engines on the A8 have thin walls implemented?

what do you mean by "thin walls"?

 

[globe]

6 hours ago, Heaven/TQA said:

what do you mean by "thin walls"?

XXL probably meant something like Capture the flag walls, it's not a raycaster but it has thin walls and despite the grid being only 16x16, the maze can be pretty complicated because of it.

With standard 1 grid square thick walls maze would be much simpler.

 

11 hours ago, xxl said:

Does any of the raycasting engines on the A8 have thin walls implemented?

Not that I know off, but modifying normal raycasting routine for this shouldn't be very complicated.

Map data would need to change though, also texture data if you want to have more than 3.

 

For example we could use bit pairs for 4 walls of a grid square.

00 = no wall, 01 - 11 = texture 1 - 3

Starting from North, going clockwise 00 01 01 01 would get you 'U' shaped 'room' the size of one grid square, all walls using texture 1.

Ray going North East would filter the South walls with AND #%00001100 when going North / up them map, and West walls with AND #%00000011 when going East.

 

Since raycaster detects 'leading edge' of the wall for this to work properly from all angles, adjacent squares would have to have walls 'touching' the walls of our 'U' tile.

So tile to the left would need East wall, tile under North wall etc...

This would also allow for different textures when looking from the inside and from the outside.

[Heaven/TQA]

14 hours ago, globe said:

XXL probably meant something like Capture the flag walls, it's not a raycaster but it has thin walls and despite the grid being only 16x16, the maze can be pretty complicated because of it.

With standard 1 grid square thick walls maze would be much simpler.

 

Not that I know off, but modifying normal raycasting routine for this shouldn't be very complicated.

Map data would need to change though, also texture data if you want to have more than 3.

 

For example we could use bit pairs for 4 walls of a grid square.

00 = no wall, 01 - 11 = texture 1 - 3

Starting from North, going clockwise 00 01 01 01 would get you 'U' shaped 'room' the size of one grid square, all walls using texture 1.

Ray going North East would filter the South walls with AND #%00001100 when going North / up them map, and West walls with AND #%00000011 when going East.

 

Since raycaster detects 'leading edge' of the wall for this to work properly from all angles, adjacent squares would have to have walls 'touching' the walls of our 'U' tile.

So tile to the left would need East wall, tile under North wall etc...

This would also allow for different textures when looking from the inside and from the outside.

ah ok. Capture the Flag like. got it... yeah... CTF uses a similar map you described with bits. map data is 256 bytes total, too.

What Paul coded in Wayout and CTF is very nice esp. CTF but it is a more "vector orientated" engine. well... using 3d maths so to say. it uses even multiplication to "scale" the view so you can make the viewport smaller or bigger by altering that "multiplicator". not sure if it based on the fact that there is a VIC20 version, too.

 

@globe I disassembled and have the source code for CTF VIC20 and A8 version and played around and started to comment on it. I even made a faster version using the "fastmul"square tables methods. Paul used an "oldschool" multiplication routine... it should be somewhere here on AA...

Edited February 23, 2022 by Heaven/TQA

[Heaven/TQA]

Midi Maze might be a raycaster with "thin" walls?

[xxl]

I made another optimizations suggested by Saint (his engine has the ability to display walls at any angle and thin walls too) but his engine is used for demos, it doesn't have a map as a grid just a set of lines. I don't know how such engine would behave when we have a lot of lines, some time ago in Chipin2010 game I used algorithm for intersecting lines and it works fast and well but for few lines while I can't imagine whole map built like this.

[Heaven/TQA]

5 hours ago, xxl said:

I made another optimizations suggested by Saint (his engine has the ability to display walls at any angle and thin walls too) but his engine is used for demos, it doesn't have a map as a grid just a set of lines. I don't know how such engine would behave when we have a lot of lines, some time ago in Chipin2010 game I used algorithm for intersecting lines and it works fast and well but for few lines while I can't imagine whole map built like this.

Is that engine of Saint 8bit engine?

 

btw what is clever on CTF is the fact that there are nearly any slow downs due to no casting rays in the distance and the ORA filler for the walls spends same amount of cycles each rendering frame…

[xxl]

5 hours ago, Heaven/TQA said:

Is that engine of Saint 8bit engine?

no, his engine is heavily optimized for demo (greedy) as I wrote walls are a set of straight line segments that can lie at different angles. He completely got rid of bit shifts during texture scaling in favor of arrays (he will probably amaze in some demo how fast 3d world on atari can be:) he gave me some ideas for optimization but I still don't see any significant increase in animation fluidity. I'm trying to keep my memory requirements sane.

[xxl]

actually something could be done already...

 

 

[invisible kid]

Cool!

[snicklin]

1 hour ago, xxl said:

actually something could be done already...

 

 

That is looking nice.

 

Would you consider writing all the texture data to a cartridge? Then use up a lot of space, but have a very fast engine?

 

[xxl]

6 hours ago, snicklin said:

Would you consider writing all the texture data to a cartridge? Then use up a lot of space, but have a very fast engine?

this is a great idea, but you need to know how much data it takes if you want to make it even faster, so you have to get rid of shift bits and masking and this means that for a 128 byte texture you will create data that takes 32 * 4 * 4 * 4 = 2KB for one texture

 

[snicklin]

11 hours ago, xxl said:

this is a great idea, but you need to know how much data it takes if you want to make it even faster, so you have to get rid of shift bits and masking and this means that for a 128 byte texture you will create data that takes 32 * 4 * 4 * 4 = 2KB for one texture

 

That is OK, use an Atarimax 8Mb cartridge and then you can have lots of textures. Who cares if you misuse the space if you produce a fast game with a lot of content?

 

Great work!

[ivop]

28 minutes ago, snicklin said:

That is OK, use an Atarimax 8Mb cartridge and then you can have lots of textures. Who cares if you misuse the space if you produce a fast game with a lot of content?

Where's the fun in that? IMHO it's cheating. One could pre-calculate all the whole frames in 80x48, and stuff them on a cartridge, and play them as a movie with PMGs overlayed for gameplay.

 

Xxl is all for original hardware, right?

[_The Doctor__]

cartridges that provide up to 2 could be considered original equipment.... using the cart as the computer and processor is slightly different territory

but we had such things in a way on cartridge back in the day as co processors etc as well....

Edited February 24, 2022 by _The Doctor__

[snicklin]

5 hours ago, ivop said:

Where's the fun in that? IMHO it's cheating. One could pre-calculate all the whole frames in 80x48, and stuff them on a cartridge, and play them as a movie with PMGs overlayed for gameplay.

 

Xxl is all for original hardware, right?

I still don't think you could fit every possible frame onto a cartridge. But if you could, I would say "Do it"! 

 

All the top demo's are full of smoke and mirrors.

 

If you compare say Space Harrier with this proposition, SH prerenders each enemy. The only difference is that it would prerender the whole screen. Anyway, this isn't worth considering as I am proposing only prerendering each texture, just the same as an enemy in Space Harrier.

 

Have no pride, just abuse the cartridge!