Smooth 3D Movement like "Wayout"?

[Heaven/TQA]

Just for the records Wayout and Capture the Flag are not raycaster engines…  

[Preppie]

1 hour ago, Heaven/TQA said:

Just for the records Wayout and Capture the Flag are not raycaster engines…  

 

Thorfdbg already explained this, you even quoted his explanation - so we know it's not raycast

 

[emkay]

1 hour ago, Heaven/TQA said:

Just for the records Wayout and Capture the Flag are not raycaster engines…  

 

The optical illusion is perfect. That's all what is needed for such a game. 

[ilmenit]

4 hours ago, Heaven/TQA said:

Just for the records Wayout and Capture the Flag are not raycaster engines…  

how do they work?

[Preppie]

38 minutes ago, ilmenit said:

how do they work?

Go back and read this post:

 

 

As he said, you draw the top edges of a wall and then use an XOR fill.

 

So if the first column of bytes in the screen was:

 

byte $00 = 00000000

byte $28 = 11000000

byte $50 = 00110000

byte $78 = 00001100

byte $A0 = 00000010

byte $CB = 00000000

byte $F0 = 00000000

 

You would XOR bytes $00 and $28 and store in byte $28

Then XOR bytes $28 and $50  and store in $50 etc.

 

Results:

 

byte $00 = 00000000

byte $28 = 11000000

byte $50 = 11110000

byte $78 = 11111100

byte $A0 = 11111110

byte $CB = 11111110

byte $F0 = 11111110

 

As a maze is vertically symetrical you only need to draw the top half and then use a custom display list to mirror the top half to the bottom.

 

 

[Preppie]

Here's a video of capture the flag with the fill removed.

 

 

As you can see, only the top edge of the maze walls are drawn, they are then reflected by the display list to the bottom.  CTF also uses a different graphics mode on the bottom half of screen to create a different perspective.  All that needs to be done now is for the XOR fill to do it's work on the top half of screen and that will be reflected to the bottom.

 

Thanks to Heaven/TQ for his orginal post

 

 

[ilmenit]

I understand what the EOR filler is, but it's only a way to draw a filled vertical walls. You still need to determine distance to the wall on the column of the screen. @Heaven wrote that these games do not use raycasting for it and this is what I was asking about.

[Heaven/TQA]

55 minutes ago, Preppie said:

Here's a video of capture the flag with the fill removed.

 

 

As you can see, only the top edge of the maze walls are drawn, they are then reflected by the display list to the bottom.  CTF also uses a different graphics mode on the bottom half of screen to create a different perspective.  All that needs to be done now is for the XOR fill to do it's work on the top half of screen and that will be reflected to the bottom.

 

Thanks to Heaven/TQ for his orginal post

 

 

Thanks for me old fart to remind where I posted it  

[Heaven/TQA]

12 minutes ago, ilmenit said:

I understand what the EOR filler is, but it's only a way to draw a filled vertical walls. You still need to determine distance to the wall on the column of the screen. @Heaven wrote that these games do not use raycasting for it and this is what I was asking about.

Well… 1983 Raycasting wasn’t born… in games as God Carmack seem to invented it with his tank game (not 3d Wolfenstein)

[Preppie]

16 minutes ago, ilmenit said:

I understand what the EOR filler is, but it's only a way to draw a filled vertical walls. You still need to determine distance to the wall on the column of the screen. @Heaven wrote that these games do not use raycasting for it and this is what I was asking about.

You only need to be able to draw the top line.  If you look at the video carefully you see the top line is mainly grey with an occasional black pixel.  Once the fill is used that line becomes a wall with black edges.

 

If you want to know how to draw the top line then that's a bit of trigonometry.

[emkay]

What the heck...

 

Could we please stand on a clear path?

 

Of course, there are tricks used to fill the screen up as fast as possible. 

 

Raycasting or not, is just a theoretical thing.

 

The game looks in the movement as fluent as Wolf 3D. 

There are walls that do a realistic 3D occlusion. So everything is fine. 

The game is also able to show smooth animated enemies, and all is done, using some 3D algorithm.

There are eve multiple positions and angles of view.

In theory , it can run at 16 fps that way. 

[ilmenit]

13 minutes ago, Heaven/TQA said:

Well… 1983 Raycasting wasn’t born… in games as God Carmack seem to invented it with his tank game (not 3d Wolfenstein)

any idea what it does exactly? 2D rotation of the wall corners over the center? Does it determine somehow cone of view to determine the points to be rotated? I assume there are too many of them on the whole map, especially for 2 players simultaneously, plus looking at the map uncovering there has a distance limit.

10 minutes ago, Preppie said:

You only need to be able to draw the top line.  If you look at the video carefully you see the top line is mainly grey with an occasional black pixel.  Once the fill is used that line becomes a wall with black edges.

 

If you want to know how to draw the top line then that's a bit of trigonometry.

Really, I understand what the EOR filler is  What I'm curious is this "bit of trigonometry", because it does not sound that simple e.g. with offscreen clipping.

Edited May 24, 2021 by ilmenit

[Heaven/TQA]

1 hour ago, Preppie said:

Go back and read this post:

 

 

As he said, you draw the top edges of a wall and then use an XOR fill.

 

So if the first column of bytes in the screen was:

 

byte $00 = 00000000

byte $28 = 11000000

byte $50 = 00110000

byte $78 = 00001100

byte $A0 = 00000010

byte $CB = 00000000

byte $F0 = 00000000

 

You would XOR bytes $00 and $28 and store in byte $28

Then XOR bytes $28 and $50  and store in $50 etc.

 

Results:

 

byte $00 = 00000000

byte $28 = 11000000

byte $50 = 11110000

byte $78 = 11111100

byte $A0 = 11111110

byte $CB = 11111110

byte $F0 = 11111110

 

As a maze is vertically symetrical you only need to draw the top half and then use a custom display list to mirror the top half to the bottom.

 

 

Rescue on Fractalus and Capture the flag use AND fillers not XOR. Koronis Rift uses XOR.

[Heaven/TQA]

Just now, ilmenit said:

any idea what it does exactly? 2D rotation of the wall corners over the center? Does it determine somehow cone of view to determine the points to be rotated? I assume there are too many of them on the whole map, especially for 2 players simultaneously, plus looking at the map uncovering there is a distance limit.

Really, I understand what the EOR filler is  What I'm curious is this "bit of trigonometry", because it does not sound that simple.

Well… in modern days I would go for “rotozoom” way of rotating around the “grid” which is basicly just 2d stepping sin/cos values…

 

how Paul did? I bet at

top of this thread it’s mentioned and I asked same question. But basicly you just rotate in 1 axis (y) and just 2d points (x,z) as height of Top is constant… that alone should help to speed… clipping is another bitch though…

[Heaven/TQA]

On 5/11/2021 at 11:10 AM, thorfdbg said:

Capture the Flag and Wayout use a very specific algorithm to draw the maze that is not so easily adapted to more complex games. It only computes the "top edge" of the maze walls, always taking the "topmost" Y position of all the walls in your view port, then draws only the upper edges (fast), and uses a super-fast unrolled self-created program to fill the walls with solid color from top to bottom. The lower edges of the maze aren't drawn at all, but rather reflected by ANTIC by using a smart display list with a LMS instruction in each line.

 

Hence, in specific, this algorithm cannot: Draw texture on the walls, or draw enemies with a different shape then that of the walls.

 

A similar algorithm was used in the Encounter! game which also only draws the upper edge of the enemies and poles, then fills downwards, and reflects the upper part of the screen downwards. It is also very restrictive in what it can draw and display.

 

Fully texctured walls and scaling of the texture and the wall requires much more computing resources and would prevent real-time performance.

 

Here some valid info?

[Heaven/TQA]

That's what Paul wrote me years back:

 

"The challenge back then was how to get something like that to run fast enough for real time on such slow systems.

 

As I recall, with the camera and world constraints I imposed, I only needed to do hidden surface removal effectively for one scan line.  I was able to order enumeration of the walls within the view frustum to be ordered by depth (something like an octree rendering algorithm), so didn't need sorting, and I think I maintained a data structure of visible wall segments for the scan line and inserted new segments into that, updating it and doing hidden wall segment removal, as the walls were enumerated, in the end having an efficient list from left to right of the visible wall segments that needed to be rendered, basing the technique on old scan line based hidden surface removal 3d rendering algorithms predating the dominance of z buffer rendering techniques."

http://www.flipcode.com/archives/The_Coverage_Buffer_C-Buffer.shtml

Edited May 24, 2021 by Heaven/TQA

[Heaven/TQA]

my disassembly and patches of Capture the Flag:
capturetheflag_a8.zip

use MADS to get the binary.
 

Edited May 24, 2021 by Heaven/TQA

[Pokeypy]

For a raycaster (only thing I know about now ), it's the same problem: Each ray is used to draw a vertical wall slice. The slice is mirrored vertically at the horizon line (if I'm correct), so the point is just, to calculate, how high above the horizon line the slice is.

So a raycaster also 'only computes the "top edge" of the maze walls, always taking the "topmost" Y position of all the walls in your view port'.

Question is, how it does it.

 

In a raycaster, the height of the wall slice depends on the length of the ray, that is, on the player's distance to the wall.

Edited May 24, 2021 by Pokeypy

[Heaven/TQA]

Carmack's first "game raycaster"
 

 

[Heaven/TQA]

another good example that you can work with solid walls:
 

and not to mention Philip Price's Alternate Realtiy, esp. the Dungeon which is a 90 deg but texture mapper... as you are not moving "in grid" steps like Bard's Tale but in "subgrid steps".

Edited May 24, 2021 by Heaven/TQA

[emkay]

1 hour ago, Heaven/TQA said:

Here some valid info?

 

No. 

It's still explaining how the filling is done. 

There is not a dot explained about the correct depth projection.

[emkay]

1 hour ago, Heaven/TQA said:

That's what Paul wrote me years back:

 

"The challenge back then was how to get something like that to run fast enough for real time on such slow systems.

 

As I recall, with the camera and world constraints I imposed, I only needed to do hidden surface removal effectively for one scan line.  I was able to order enumeration of the walls within the view frustum to be ordered by depth (something like an octree rendering algorithm), so didn't need sorting, and I think I maintained a data structure of visible wall segments for the scan line and inserted new segments into that, updating it and doing hidden wall segment removal, as the walls were enumerated, in the end having an efficient list from left to right of the visible wall segments that needed to be rendered, basing the technique on old scan line based hidden surface removal 3d rendering algorithms predating the dominance of z buffer rendering techniques."

http://www.flipcode.com/archives/The_Coverage_Buffer_C-Buffer.shtml

So he was somehow doing a fixed occlusion culling . Not calculating, but sorting. Makes sense on such a small machine. 

Clever decisions...

Still not explained, how things get moved around. 

 

[ivop]

How about just precalculating everything?

 

- subgrid of 3x3

- 3 angles (0, 30, 60 degrees)

- 8 (possible) cubes in view

- 80 bytes per line, height and colormask tuple

 

9*3*8*80 = 17280 bytes for a fake raycaster

 

For each possible cube in view, the 80-byte line descriptions are overlayed, and then filled and mirrored by Antic.

 

There are subgrid * angles = 3*3*3 = 27 different combinations of which cubes are in view.

 

Edit: instead of a colormask, you can also store a horizontal index into a texture. The vertical scaling of the texture can be calculated by the height value and the maximum height of a cube. Simple vertical fillers won't work anymore, and neither would mirroring by Antic, but it seems possible.

 

Edit2: If the colormask is not stored, they are assumed to be %11000000, %00110000, etc... depending on the x position. Texture is ANDed with the mask, but is only used if height != 0. It might be helpful to store four shifted versions of each texture, if space allows that. BTW the assumption of 8 cubes in view (you are standing in the 9th cube) is based on a corridor map. If you want wider "streets" more cubes get in view.

Edited May 24, 2021 by ivop

[emkay]

1 hour ago, ivop said:

 

 

9*3*8*80 = 17280 bytes for a fake raycaster

 

 

 

Sorry, but to use "fake" is an unneccesarily down pushing term. 

Precalculation is not fake. 

It might limit things, but those small computers have their limits anyways.

 

Seeing the Vic20 Version running at the half framerate, doing also this "precalculation" tells stories. 

 

I'm still pissed, when people claim that "3D presentation using character mode usage" is 3D , just because the rather limited movement can be calculated in "realtime" , while doing sorted 3D movement on a real projcted screen that allows more moving in angles and positions is named fake.

You know, I'm talking about some C64 demos that "optimize" things there, but never show "real 3D". Just some fanboy on the C64 sat the rule, so it is given ? 

[ivop]

10 minutes ago, emkay said:

Sorry, but to use "fake" is an unneccesarily down pushing term. 

Precalculation is not fake. 

It might limit things, but those small computers have their limits anyways.

Thanks. Hence the wink

 

10 minutes ago, emkay said:

Seeing the Vic20 Version running at the half framerate, doing also this "precalculation" tells stories. 

You have a link to that?

 

10 minutes ago, emkay said:

I'm still pissed, when people claim that "3D presentation using character mode usage" is 3D , just because the rather limited movement can be calculated in "realtime" , while doing sorted 3D movement on a real projcted screen that allows more moving in angles and positions is named fake.

You know, I'm talking about some C64 demos that "optimize" things there, but never show "real 3D". Just some fanboy on the C64 sat the rule, so it is given ? 

I have no opinion on this C64 thing, but even so called realtime routines use LUTs most of the time, or you are looking at a slide show. How many look up tables before it's not realtime anymore? IMHO use as many tables as needed, and that fit in standard RAM