Ray Casting Engine Demo

[Joe Musashi]

When the 3d graphics engine thread was revived a few weeks ago, it inspired me to try this myself. I always wanted to see how a 3D maze would look on the VCS if rendered with playfield graphics at 60Hz.

 

So, I made a demo that lets you wander around a 3D area using a full 40 bits wide asymetrical playfield. However, this is only possible by cheating: The demo is using DCP+ and ARM code to do the ray casting and playfield drawing, the 6507 only handles the display kernel. (It required already some optimization on the ARM side, so a full game would either have to use a lower frame-rate or a lower resolution.) This also means you will need a Harmony/Melody cart to run it on a real machine.

 

There are two color schemes to choose from: Solid walls with a single color, or alternatively blinds with two wall colors.

 

 

Controls are as follows:

• Button released:
  • Joystick Left/Right - move camera left/right
  • Joystick Up/Down - move camera forward/backward
• Button pressed:
  • Joystick Left/Right - rotate camera counter-clockwise/clockwise
• Console Reset - reset camera to initial parameters
• Console Left Difficulty - A: move speed high, B: move speed low
• Console Right Difficulty - A: two-color walls, B: one-color walls

 

I'm tempted to make a 3D version of Combat, but I don't have the time. Actually, the Combat maze is part of the demo map .

The complete source is attached below. If anyone wants to make a Doom/Combat/etc. game for the VCS, feel free to use this code.

 

RayCastDemo_140824_NTSC.bin

RayCastDemo_140824_PAL60.bin

RayCastDemo_140824.zip

[GroovyBee]

Very cool!

[LS_Dracon]

Very cool indeed!

I like the venetian blind option most.

[+SpiceWare]

Impressive!

 

I like your DPC_SET_FETCHER macro.

 

Has anybody else done DPC+ with ARM code (besides batari's DPC+ Kernel for bB that is)?

[Joe Musashi]

Impressive!

 

I like your DPC_SET_FETCHER macro.

 

Has anybody else done DPC+ with ARM code (besides batari's DPC+ Kernel for bB that is)?

 

Thank you! I couldn't have done it without your DPC+ code samples!

 

Hopefully, more people will try ARM coding. There is quite some potential for interesting demo effects.

[+SvOlli]

Hopefully, more people will try ARM coding. There is quite some potential for interesting demo effects.

 

There is potential, but using anything but vanilla 2600 is considered cheating. My usage of SARA RAM was one of the most discussed topics on "Bang!". I could make the point that a few original Atari releases were using SARA as well (like Dig Dug, which I owned "back then").

[Mr SQL]

 

There is potential, but using anything but vanilla 2600 is considered cheating. My usage of SARA RAM was one of the most discussed topics on "Bang!". I could make the point that a few original Atari releases were using SARA as well (like Dig Dug, which I owned "back then").

 

OK fair enough 32-bit code is not 6502 asm, but none of this is cheating, it's just a reference point in time:

 

2K or 4K Vanilla: 70's

4K or 8K with SARA or 6K SuperCharger: '82

12K with CBS RAM: '83

---------------------------------------------------------

Big memory games: late 80's through early 90's

---------------------------------------------------------

32-bit ARM games: 2000+

128-bit Emotion Engine* games: 2000+

 

*The mod is easy - you just glue a PS2 on top of a Vader (the colour schemes match!) and you've got an S-Video and stereo out mod plus DVD, 32 MB of additional RAM and modern controller ports - you can even boot Linux and literally develop on the Atari

 

Can you link the Bang! forum discussion?

[Thomas Jentzsch]

There is potential, but using anything but vanilla 2600 is considered cheating.

I see where you are coming from. But effectively it is just another category. So you shouldn't compare e.g. 2K demos with 4K demos, and demos with 128 bytes RAM with demos using SARA.

 

Probably the problem for the demo scene is that with additional parameters (more RAM/ROM/CPU power etc.) your are fractioning the competition a lot. But I suppose this is not the first time additional hardware is available, so you must have found a solution for the problem already. Right?

 

For the homebrewers the situation is different. Here the customer usually doesn't care that much about the technical details. If it runs on the console, it is legit. This can be discouraging for those people, who restrict themselves to certain parameters (e.g. no ARM support). Because from customer perspective, your creation seems worse than the game created with e.g. ARM support.

 

To solve this problem, you have filter the feedback you get. From technically uninformed customers, all feedback regarding packaging and other things not depending on the hardware restrictions is completely valid, everything else you have to question. Worst case you have to ignore it, but quite frequently the feedback is still valid or at least valuable. From other people, e.g. other homebrewers who understand the different restrictions, the feedback will still be 100% OK.

[Kylearan]

The extra RAM was not the problem with Bang!. What SvOlli fails to mention is that he didn't tell the audience at the competition that extra RAM is used. So people saw the demo, compared it to other VCS demos they know (none of which so far has used extra RAM) and voted accordingly.

 

Using extra features in itself is not cheating of course, and I doubt anyone said this (or would say this). Personally, I find it unfortunate because as Thomas says it fragments an already tiny scene, but I can also understand that it's fun to use the SARA chip.

[+SvOlli]

Can you link the Bang! forum discussion?

Most of written discussion happend on pouet: https://www.pouet.net/prod.php?which=62955

 

I see where you are coming from. But effectively it is just another category. So you shouldn't compare e.g. 2K demos with 4K demos, and demos with 128 bytes RAM with demos using SARA.

There mainly are two categories a VCS demo would compete: either "Old Skool" or "Wild". I was prepared to argue that using SARA is still oldskool, since it's a chip that's been used by Atari a couple of times themselves, while the VCS was still being produced. That kind of argument definately won't work with DPC+ calculating stuff for the 6507.

 

So you could still show a demo using DPC+, but it wouldn't qualify as "Old Skool" anymore, and you have to present it as a "Wild" entry. But I still think one can have lots of fun creating a wild entry with a predefined route to move inside the maze...

 

But right now I'm spending most of my free time hacking around my 32x16 LEDs display.

[Thomas Jentzsch]

Most of written discussion happend on pouet: https://www.pouet.net/prod.php?which=62955

Not as heated as I initially thought.

 

I agree that using the SARA is still oldschool. IMO everything that was used during production is oldschool. So even 1K RAM would be OK. Nevertheless there is huge a gap between 2K ROM/128 bytes RAM and e.g. 32K ROM/1K RAM. So oldschool is a too broad term for a competition. Probably each compo should define clearly what the restrictions are.

 

But right now I'm spending most of my free time hacking around my 32x16 LEDs display.

I hope your are not lost for the 2600.

[+SpiceWare]

So you could still show a demo using DPC+, but it wouldn't qualify as "Old Skool" anymore, and you have to present it as a "Wild" entry. But I still think one can have lots of fun creating a wild entry with a predefined route to move inside the maze...

 

DPC (no +) should qualify as Old Skool - Activision used it for Pitfall 2.

 

http://atariage.com/forums/topic/159670-dpc-sprite-demo/

 

http://atariage.com/forums/topic/159048-dpc-music/

[Mr SQL]

Not as heated as I initially thought.

 

I agree that using the SARA is still oldschool. IMO everything that was used during production is oldschool. So even 1K RAM would be OK. Nevertheless there is huge a gap between 2K ROM/128 bytes RAM and e.g. 32K ROM/1K RAM. So oldschool is a too broad term for a competition. Probably each compo should define clearly what the restrictions are.

 

I hope your are not lost for the 2600.

No, no way 32K ROM 1K RAM is old school, that spec is after 1984, after 1986 even - c'mon that is so monster

[RevEng]

I see where you are coming from. But effectively it is just another category. So you shouldn't compare e.g. 2K demos with 4K demos, and demos with 128 bytes RAM with demos using SARA.

Yup, I couldn't agree more. One of the few highly placed "oldskool" entries that I downloaded from pouet.net uses several illegal/undocumented opcodes. If "used in the commercial life of the console" is our yardstick for oldskool, then one could argue that illegal opcodes don't qualify.

 

"oldskool" or "wild" are just too coarse to be meaningful. No matter how warm and fuzzy calling an entry "oldskool" may make us feel, its pretending there's a level playing field between the different categories. Controversy is bound to follow.

[iesposta]

More engine demos!

What if the walls were a tank and cubes.

It would be Battlezone Arcade 2600!

[Mr SQL]

Yup, I couldn't agree more. One of the few highly placed "oldskool" entries that I downloaded from pouet.net uses several illegal/undocumented opcodes. If "used in the commercial life of the console" is our yardstick for oldskool, then one could argue that illegal opcodes don't qualify.

 

"oldskool" or "wild" are just too coarse to be meaningful. No matter how warm and fuzzy calling an entry "oldskool" may make us feel, its pretending there's a level playing field between the different categories. Controversy is bound to follow.

 

RevEng,

If the opcodes were not used/unavailable to programmers in the 70's and 80's then you have a good argument they are not old school, though they are certainly cool

 

Tom had a good point many non-programmer folks cannot fathom these differences though; you could literally glue a PS2 to the Atari as in my silly example and they would imagine PS2 games are Atari games simply because the PS2 once glued on top runs in harmony; indeed, place you hand on the Atari and the virbrational whirl and click of the dual spindle and servo mechanisms in the PS2 permeate with a pervasive effervessence that provides convincing tactile and audial feedback the machines have become one, merged together in a technological malestorm like Decker and Voyager in the Star Trek motion picture

[Omegamatrix]

To solve this problem, you have filter the feedback you get. From technically uninformed customers, all feedback regarding packaging and other things not depending on the hardware restrictions is completely valid, everything else you have to question. Worst case you have to ignore it, but quite frequently the feedback is still valid or at least valuable. From other people, e.g. other homebrewers who understand the different restrictions, the feedback will still be 100% OK.

You've just taken a hammer, and completely hit the nail on the head. Well put.

[+SvOlli]

I hope your are not lost for the 2600.

Nope. But after "shooting out" everything I had done on the 2600 for more than two years in one big blast of two demos, I feed kind of empty. Since then, I only had one idea for a new demo-part. There's been other stuff, that I've contributed to, like "Flippin' The Dots", even though it was not "my show" since most of the code was written by someone else. Since the flipdot display were just borrowed and are not available for buying, I wanted to have something with a similar attitude and so I went for true color LEDs.

 

The 2600 still is and ever will be the most f*cked up system I've, and I love it for that. Right now I'm preparing an hour-long talk about "Bang!" that will be done on Hackover, visit me there, if you like. As far as I know, this will be also recorded, so I'll stick to English language for you guys here. On #vcsdev, there's been some talk about a collaboration demo where everyone gets his "own bank". This is an opportunity that I won't skip.

 

DPC (no +) should qualify as Old Skool - Activision used it for Pitfall 2.

This also is true about the memory extensions on the VIC-20, but there's also been big fighting on what's the "standard" environment of a demo. Is it the "stock" one, or rather the one "with all the unnecessary hardware bugs removed"?

 

C-64 has it so much easier: it's always been "vanilla" C-64 and a "vanilla" 1541. One of the many reasons why it's still the platform with the most demos.

[Kylearan]

Nevertheless there is huge a gap between 2K ROM/128 bytes RAM and e.g. 32K ROM/1K RAM. So oldschool is a too broad term for a competition. Probably each compo should define clearly what the restrictions are.

Agreed. But the problem is that the VCS demo scene is too small, so the few VCS demos that are released per year have to be put in the general "oldschool" or "wild" category, or otherwise there would be no competition. Fragmenting that even more (4K vs. 32K etc.) is, unfortunately, not an option.

 

The only exception is SillyVenture in December, which is an Atari-only demo party and has its own 2600 category with fixed and clear rules (max 32 kB ROM, no extra cartridge RAM or DPC allowed.) There at least people don't have to compete with C64, Spectrum or even Amiga demos, and that's where I will release my next demo. I hope there will be some competition.

 

If however all the fine folks from AtariAge would code a demo inbetween games, that would change the situation completely. (But then you could say we demo sceners should code a game inbetween demos...)

 

Anyway, back to coding; 4 parts finished, 4 to go!

[Thomas Jentzsch]

I understand that the scene is too small. But the definition for the "oldschool" or "wild" categories could vary every year (or between different demo parties).

 

E.g one year "oldschool" means 4K, not extra RAM, next year 16K with SARA, then 1K ROM etc... Same for "wild", one year you allow DPC+ (ARM), next year you don't. So the challenges vary over the years and every coder gets chance to explore new territory.

Edited September 5, 2014 by Thomas Jentzsch

[SeaGtGruff]

When do we get Skyrim 2600?

 

I don't know if it's been mentioned yet, but there's a slight "bug" in the two-color version-- namely, as you're moving or panning there's a lag between the two colors from one frame to the next. I'm not sure if there's any way to fix it, which is why I say "bug" in quotes.

 

Now all you need to do is completely rewrite the engine to use ChronoColor or whatever Andrew calls it, so you can draw eight-color worlds!

[roryjr]

That's so cool. How you do it doesn't matter to me. Just that it runs on my 2600.

[Joe Musashi]

When do we get Skyrim 2600?

 

I don't know if it's been mentioned yet, but there's a slight "bug" in the two-color version-- namely, as you're moving or panning there's a lag between the two colors from one frame to the next. I'm not sure if there's any way to fix it, which is why I say "bug" in quotes.

If you zoom (move forward) color changes are not as smooth as in the one-color version because the vertical resolution is essentially halved due to the blinds.

 

I don't know how there could be lag when moving sideways because the alternating colors are fixed. But I can have another look.

 

Now all you need to do is completely rewrite the engine to use ChronoColor or whatever Andrew calls it, so you can draw eight-color worlds!

It would be interesting to use some of the methods from the Parrot rendering thread. For example, if you had a fully unrolled kernel and colors in A,X,Y you could use just stores to change the color every 9 pixels, but that would probably be to coarse.

[Gip-Gip]

Amazing feat, even if using ARM code nearly the entire process.

[+Nathan Strum]

Nice! So… I, Robot anyone?