Smooth 3D Movement like "Wayout"?

[Pokeypy]

Hi,

as mentioned somewhere else, I really was impressed by that 3D maze example.

Ported it to Pygame.

Then I saw this recent video, which showed several good A8 games. I knew some of them, others were new to me. So, good suggestions for me. In particular, I didn't come across "Wayout" back then (8:35 in the video) (its successor "Capture the Flag" though).

Someone in the comments was also really impressed, because the graphics are even close to "Doom". Which was a sensation ten years later on a much faster machine (PC).

 

 

So: Already having the more static, "single step" maze above, would it be possible to create something like "Wayout" with this smooth 3D movement and lots of different perspectives? How would this be done? If you want to keep it on the Atari, in C maybe? To be honest, I don't have a clue at the moment. Today, you probably would just fire up "Unity", and it would do the thinking for you. But how would you code that by hand? Has anyone an idea and would like to share the know-how?

Edited May 9, 2021 by Pokeypy

[Wrathchild]

C would be too slow

 

have you seen Project-M 2.0?

 

6

Edited May 9, 2021 by Wrathchild
added video

[glurk]

That's an early game use of a technique known as raycasting --> wikipedia article: https://en.wikipedia.org/wiki/Ray_casting

 

It involves rather complex matrix math, and would have to be written in really optimized machine code, especially to do textured walls and moving objects.  Wolfenstein 3D (Doom precursor) was really what made the technique ubiquitous.

[globe]

2 hours ago, Pokeypy said:

So: Already having the more static, "single step" maze above, would it be possible to create something like "Wayout" with this smooth 3D movement and lots of different perspectives?

If you want to build upon 'single step' maze something like this

https://www.youtube.com/watch?v=8FMDIEGeWwk

could be the result.

It's still 'single step' and 90 degrees rotation only, but in-between animations make it look smooth.

 

If you want to go for completely free movement though the maze, you're probably going to have to start from scratch.

Here's a great tutorial about the math involved that gets posted here occasionally:

 

https://permadi.com/1996/05/ray-casting-tutorial-table-of-contents/

[emkay]

4 hours ago, Pokeypy said:

Hi,

as mentioned somewhere else, I really was impressed by that 3D maze example.

Ported it to Pygame.

Then I saw this recent video, which showed several good A8 games. I knew some of them, others were new to me. So, good suggestions for me. In particular, I didn't come across "Wayout" back then (8:35 in the video) (its successor "Capture the Flag" though).

Someone in the comments was also really impressed, because the graphics are even close to "Doom". Which was a sensation ten years later on a much faster machine (PC).

 

 

So: Already having the more static, "single step" maze above, would it be possible to create something like "Wayout" with this smooth 3D movement and lots of different perspectives? How would this be done? If you want to keep it on the Atari, in C maybe? To be honest, I don't have a clue at the moment. Today, you probably would just fire up "Unity", and it would do the thinking for you. But how would you code that by hand? Has anyone an idea and would like to share the know-how?

 

That's the correct way of planning a 3D view game. 

 

The most speedup you see in Wayout! is the hardware re use of some calculated lines. 

It's the fastest thing you can get on old Computer pre 1985.

 

Since the screen is rather small, the filling of the lines might get quick. 

To the left and the right of the screen you can use a Player to hide unwanted edges. 

Also, you don't have to fill equal lines more than one time. 

Every equal looking line can get copied by ANTIC. 

You won't get much details to the walls, but the playability is like on a 386 PC .

Well, the game uses Antic E, but using Antic D would allow to use a 4 times bigger window

 

"C" might be useful to get things running. ANTIC (and GTIA) is helping a lot there speeding things up. 

 

 

 

[Pokeypy]

Thanks for your answers!

 

@Wrathchild:

Quote

C would be too slow

I see. In the end, I'll probably port it (again) anyway.
It's just, if you guys talk Atari assembly, I don't understand anything.

Quote

have you seen Project-M 2.0?

Not yet, I'll take a look.

 

@glurk:

Quote

That's an early game use of a technique known as raycasting --> wikipedia article:
https://en.wikipedia.org/wiki/Ray_casting

Thanks! I'll read about that and see, what I can make of it.

 

@globe:

Quote

If you want to build upon 'single step' maze something like this

https://www.youtube.com/watch?v=8FMDIEGeWwk
could be the result.
It's still 'single step' and 90 degrees rotation only, but in-between animations make it look smooth.

Very impressive. Didn't know, the C64 could do that.

 

@emkay:

Quote

The most speedup you see in Wayout! is the hardware re use of some calculated lines. It's the fastest thing you can get on old Computer pre 1985. Since the screen is rather small, the filling of the lines might get quick. To the left and the right of the screen you can use a Player to hide unwanted edges. Also, you don't have to fill equal lines more than one time. Every equal looking line can get copied by ANTIC.

"C" might be useful to get things running.

That's what I thought. I just wondered how it was done as a concept.

I had an idea: At the moment, I just have these big squares (inside the maze). The player moves from one square to another.
What, if I divide each of the squares into a 5x5 board. Now the player stands at position "3,3" of the square and moves to position "3,3" of the next square.
When I had unblocked keyboard reading, I could make the player move from "3,3" to "3,2", then "3,1", then "3,5" of the next square, "3,4" of the next square, then "3,3" of the next square.
And I'd have to calculate the small changes in the perspective (probably using ray casting).
I wouldn't get these "animations" from "3,3" to "3,3" like in the C64 game then. The player could also stand at "2,1" for example (close to the wall), like in "Wayout".
You know, maybe that could work.

 

Edited May 9, 2021 by Pokeypy

[emkay]

36 minutes ago, Pokeypy said:

T

 

@globe:

Very impressive. Didn't know, the C64 could do that.

 

The impressive part is that it exists on the C64 and not on the Atari

 

Using character mode is an other option. 

It would work on the Atari as well. 

This time the "line to draw" is the character mode. 

It's possible to reuse the characters, or the character mode line (or combined) , to save a lot CPU time. 

 

 

 

36 minutes ago, Pokeypy said:

@emkay:

That's what I thought. I just wondered how it was done as a concept.

I had an idea: At the moment, I just have these big squares (inside the maze). The player moves from one square to another.
What, if I divide each of the squares into a 5x5 board. Now the player stands at position "3,3" of the square and moves to position "3,3" of the next square.
When I had unblocked keyboard reading, I could make the player move from "3,3" to "3,2", then "3,1", then "3,5" of the next square, "3,4" of the next square, then "3,3" of the next square.
And I'd have to calculate the small changes in the perspective (probably using ray casting).
I wouldn't get these "animations" from "3,3" to "3,3" like in the C64 game then. The player could also stand at "2,1" for example (close to the wall), like in "Wayout".
You know, maybe that could work.

 

You will know, if you try it out

[ivop]

1 hour ago, Pokeypy said:

What, if I divide each of the squares into a 5x5 board.

I would go for 4x4. You know, multiples of two, easier to match and compare to

[emkay]

Just now, ivop said:

I would go for 4x4. You know, multiples of two, easier to match and compare to

I quess, he wants to use 5x5 to have the middle of the path calculated correctly.

[ivop]

1 hour ago, emkay said:

I quess, he wants to use 5x5 to have the middle of the path calculated correctly.

Good observation. Once the extra bit is used, 7x7 might work even better, if that doesn't inflate lookup tables.

[thorfdbg]

On 5/9/2021 at 11:28 AM, Pokeypy said:

So: Already having the more static, "single step" maze above, would it be possible to create something like "Wayout" with this smooth 3D movement and lots of different perspectives? How would this be done? If you want to keep it on the Atari, in C maybe? To be honest, I don't have a clue at the moment. Today, you probably would just fire up "Unity", and it would do the thinking for you. But how would you code that by hand? Has anyone an idea and would like to share the know-how?

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.

 

[Pokeypy]

Project update (Python/Pygame):

Couldn't do the smooth movement yet. But took the first steps: Could understand better, what the drawing routines do (of the C example I mentioned in the first posting, not of "Way Out" itself). And could make the walls solid (with a lot of help from the Pygame library).

Code still is here. Screenshot:

 

Edited May 12, 2021 by Pokeypy

[Pokeypy]

Thanks for the positive feedback! Today, I found some interesting tutorials about ray casting (for those, who're still interested in the subject). The principle is, the player sends out virtual rays in the maze, like the sonar of a submarine or a bat (or the light of a flashlight). By hitting a wall with these "rays", the distance to the wall can be measured. Walls that are further away can then be drawn in a darker color, which gives the scenery a kind of "natural", but also gloomy look.

I found this tutorial by a Russian programmer for Pygame, with the link to the code in the video description (the second step of his tutorial is what I'm interested in; his code is also quite readable to me, which is nice). He also wrote a basic or light version of "Doom" in Pygame. Python/Pygame isn't quite fast enough to run a full "Doom"-clone, so I think, it's quite amazing, what he's achieved:

 

 

And there's another tutorial, that explains the technique. It's in JavaScript, so the examples also run directly in your browser, if you want to take a look.

So after all, I'm quite confident, something like "Way out" or "Encouter" could be realized in Pygame. On the Atari 800 XL, what they did back then was probably the upper limit.

(That's alright, I mean, even the Amiga 1200 was struggling with these kind of calculations.)

Edited May 13, 2021 by Pokeypy

[Preppie]

There's a number of videos about raycasting on youtube, one of the better ones I've found is:

 

 

And OLC is always good to watch, whatever he's doing.

 

 

 

[Pokeypy]

On 5/14/2021 at 8:20 AM, Preppie said:

There's a number of videos about raycasting on youtube, one of the better ones I've found is:

 

 

 

Ok, followed this tutorial. My (Python) results would be here.

[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.

 

Are you sure in the top left most only? Because I was going into the engine and talked with Paul few years ago… where did you get that info? Paul doesn’t remember details but it’s using top edge span buffer… remember that I might posted the “without fill routine” patch here  

[Heaven/TQA]

On 5/14/2021 at 8:20 AM, Preppie said:

There's a number of videos about raycasting on youtube, one of the better ones I've found is:

 

 

And OLC is always good to watch, whatever he's doing.

 

 

 

Did we not all watched that from time to time  

[emkay]

10 hours ago, Heaven/TQA said:

Did we not all watched that from time to time  

The point still is to get the perfect mix of 3D calculations and hardware possibilities .

 

  

[emkay]

If people were so keen in the advantage of using character modes for fast masking of the border, why did no one of them use Antic mode 7 (Graphics 2) yet? Possibly Antic 6?

 

This is the fastest mode (using higher graphics details than just blocks), and this is the cause for being used in Basic games. 

Fastest CPU (very low DMA) plus ultra fast screen handling. 

You might get 2 colors for every graphics, but the cells offer 5 colors to set objects to colors.

Still PMg is free to add details, HUD, extra graphics, protagonist's weapon...

 

[Preppie]

The description of how wayout creates the screen got my gears turning so I threw together a little demo in FastBasic.

 

 

 

First one is all FastBasic, second has had the exor fill routine replaced with a bit of assembly.

 

The display list is 

30x mode 7

36 lines that copy line 30

30 lines that reflect the top 30 (line37 is 30, 38 is 29, 39 is a copy of 28 etc.)

Just need to draw the top lines and the fill and DL do the rest.

 

The garbled screen at the start is the 2 display lists for page flipping the screen.  Both DLs and both screens fit into the area of standard gr.7 memory

 

I think I may have my next 10 liner in the works

 

Edited May 21, 2021 by Preppie

[vitoco]

36 minutes ago, Preppie said:

I think I may have my next 10 liner in the works

I'd like to see "Where's my Cheese? II" 

 

[Preppie]

38 minutes ago, vitoco said:

I'd like to see "Where's my Cheese? II" 

 

yep   it's a fairly short routine and leaves PMs available for other stuff.

[Pokeypy]

@Preppie: Nice one!

[Pokeypy]

I also worked a bit more on this (still in Pygame). In this link is my version 2.0. New features in the description there. Best thing is, larger maps can be used now and a scrolling 2D map viewport ist displayed (which wasn't described in the tutorial). There's a screenshot below.

I think, that's about as far as I go now. Until I get inspiration for a good game to use it. Would be my first real game then.

This version already feels a bit like a game actually.

 

Edited May 21, 2021 by Pokeypy

[dmsc]

Hi!

9 hours ago, Preppie said:

The description of how wayout creates the screen got my gears turning so I threw together a little demo in FastBasic.

 

First one is all FastBasic, second has had the exor fill routine replaced with a bit of assembly.

 

The display list is 

30x mode 7

36 lines that copy line 30

30 lines that reflect the top 30 (line37 is 30, 38 is 29, 39 is a copy of 28 etc.)

Just need to draw the top lines and the fill and DL do the rest.

 

The garbled screen at the start is the 2 display lists for page flipping the screen.  Both DLs and both screens fit into the area of standard gr.7 memory

 

I think I may have my next 10 liner in the works

Great, so, I now have to add an XORMOVE statement to FastBasic