Raycasting on VCS

[kezax]

Hello guys,

 

I would like to share with you something new I have managed to code for the VCS, it is based on Joe Musashi's idea about how to display a raycasted 2D map (http://atariage.com/forums/topic/229083-ray-casting-engine-demo/)

 

 

 

Last week-end, there was the SV2018, a Atari only demo party in Poland, and with some friends we released there a PAL demo featuring that effect:

https://www.pouet.net/prod.php?which=78742

 

And as I have been using this AtariAge website since the very beginning (1 year and 2 months ago), and found a lot of help and resources to understand how to code on this amazing hardware, I told myself it is time to give back to the community.

 

So first, there is a GitHub link about the raycasting, with explanations, interactive 2600 demo (you can move with joypad), and C++/SDL program which was used to validate the algorithm before implementing in ASM, then to generate data tables for the ASM too. Here it is:

https://github.com/Javanaise/vcs-demo-raycaster

 

Also, I would like to thank in no particular order, SeaStGruff, Joe Musashi, Tjoppen, SvOlli, Darell Spice Jr, Thomas Jentzsch, eshu, Omegamatrix, Glenn Saunders, Andrew Towers, Martin Arndt, for all their teachings, findings, sharings, and for also being great sources of inspiration Thanks everyone, you are awesome.

 

The interactive demo for the raycast is adaptable for the NTSC system, but might require as it was finally done in the demo, that the "converter" routine (from raycast data to ready to display data), uses fastest speed algorithm, as described in the explanations, and forced to run only between VSYNC and frame drawing (this is where there is more time). In that version even in PAL, the screen sometimes jumps a little bit, because conversion occurs between end of frame draw and next VSYNC, and sometimes it's missing a little bit of time to complete before end of timer

 

Enjoy,

 

Kezax

RaycastDemo.bin

Edited November 13, 2018 by kezax

[Coolcrab]

That could be made into a cool maze game! Maybe pacman 1st person?

[AkashicRecord]

That could be made into a cool maze game! Maybe pacman 1st person?

Maybe if you drastically cut down the visual area...like only use PF2...?

 

I can't imagine squeezing any sort of [good] game logic in between the raycasting and rendering. This demo seems RAM-heavy without even looking at any code yet.

 

The fabled Swordquest: Airworld would merit this sort of treatment...that, or Wizardry.

Edited November 13, 2018 by AkashicRecord

[kezax]

To add rendering of a sprite to the rendering of the raycast is possible but not easy - not much time left. But it is possible, it was done in the final demo (including handling of a mask - to simulate going in front or behind a wall...). Sprite takes 8 bytes more RAM to be handled properly.

 

Agree with AkashicRecord, it is heavy on RAM - and most interestingly, not fixed RAM size - depends on what is displayed. So, all the game logic variables which are actually const should definitely not be coded in RAM. And correct number of bits should be used, too.

 

In the demo version, 24 bytes of RAM are reserved for multiplication table pointers, to avoid having to set any of them to the same value, more than once. It was a try to write fastest possible raycast implementation. However, holding some of these pointers represent very little gain of time (a few scanlines) and finally more waste of RAM than anything else, so I guess their space could be reused for something else.

 

Also, there is not enough time to compute that at 50Hz, maintaining the display. One new frame is computed on an average of 3 or 4 frames per second.

[+Atari_Warlord]

That could be made into a cool maze game! Maybe pacman 1st person?

 

Or maybe Doom?

[Coolcrab]

 

Or maybe Doom?

Yes please!