Jump to content

Wolfenstein 3D - raycasting demo with textures 1.3.0

   (9 reviews)

5 Screenshots

About This File

Raycaster demo (written in c and assembly)

This version is a big improvement in performance: it now runs at 10+ fps! 🙂

I am quite happy with the speed. The demo plays quite nicely now.

See below description of version 1.3.0 for details.

---
This is a raycaster demo written in c and assembly for the Commander x16. I've been trying out the x16 and thought it would be a cool idea to start working on a raycaster.

Ultimately it would be great if "Wolfenstein 3D" can somehow be ported to the x16. That would be a BIG challenge though! 😉

This is how it looks now:

raycasting_demo_1.3.0a.gif

Speed improvements in 1.3.0:

Now running at 10+ fps! 🙂

- Using zero page addresses for pretty much all my variables
- Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication
- Inlined the fast multipliers, so less copying of values, no jsr and rts
- Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done)
    - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray
    - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused
- Cleaned up the main loop and several other parts
- Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) 🙂
 

New in this version 1.2.0:

- draw functions have been ported to assembly. Much faster!
- dda casting functions have been ported to assembly. Much faster!
- drawing textures!
- automatic generation of routine to draw ceiling and floor (only 4 cycles per plain pixel)
- automatic generation of around 512 routines for drawing textures (only 8 cycles per textures pixel)
- using joystick controls (you can use arrow keys and alt to control, you can hold down keys)
- a few textures from Wolfenstein 3D (shareware version) have been added (loaded at startup)
- changed the map to look like the first level in Wolfenstein 3D
- added a border around the render area, just like Wolfenstein 3D

Usage

Unpack the zip. Make sure you have the .BIN files in the same folder as the source files.

To compile: (this assumes cc65 is installed)

    cl65 -t cx16 -o RAY.PRG ray.c ray_asm.asm -O3

To run:

    x16emu.exe -prg RAY.PRG -run

To play:

    up - move forwards
    down - move backwards
    left - turn left
    right - turn right
    alt-left - strafe left
    alt-right - strafe right

To debug:
    p - turn on log screen
    o - turn off log screen
    t - turn on test ray
    l - rotate test ray left
    j - rotate test ray right

Known issues (1.2.0)

- Sometimes there is a corner of a wall not drawn correctly
- Since there is no real V-sync you get "shearing" in the screen (requires double buffering)

 Next up:
- Lots of speed improvements
- Lots of cleanup of code (its messy now)
- Add a time-per-frame indicator (using a vsync interrupt counter)
- Mooaarr wall-textures!
- Double buffer to prevent shearing
- Show a map on the screen
- Bigger map (limit is now 16x16)
- Opening doors
- Add (scaled) "sprites"
- Lamps (scaled) hanging from ceiling
- Stats in lower part, gun visible
- AI, enemies

Having fun! 🙂

Jeffrey


What's New in Version 1.3.0   See changelog

Released

This verion is a big improvement in performance: it now runs at 10+ fps! 🙂

Speed improvments in 1.3.0:

- Using zero page addresses for pretty much all my variables
- Using fast multipliers that use "square" tables: https://codebase64.org/doku.php?id=base:seriously_fast_multiplication
- Inlined the fast multipliers, so less copying of values, no jsr and rts
- Re-using the somewhat "static" parts of the multiplications, so it won't be re-loaded/calculate each ray (this was harder than it sounds, quite of bit of refactoring done)
    - Cosine and Sine fractions are player-related, and even though they are negated sometimes, they (that is their squares) could be reused for (almost) each ray
    - The (square of the) fraction of the tile the player is standing in -to be used for calculating the initial x/y interception for each ray- could be reused
- Cleaned up the main loop and several other parts
- Replaced the 16-bit slow divider with a 512-entry table: distance2height (major improvement!!) 🙂

Known issues (1.3.0)

- Sometimes there is a corner of a wall not drawn correctly (although not detected for some time, maybe this bug is gone?)
- Since there is no real V-sync you get "shearing" in the screen (requires double buffering)


try_it

Yes

try_it_start_prg

RAY.PRG
  • Like 14
 Share


User Feedback

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest

rje

   2 of 2 members found this review helpful 2 / 2 members

This looks good.  It's reactive enough to be playable.  I'm sure adding game elements will slow things down a bit further, but this is very impressive!

The strafe-move doesn't seem to work for me 😞, but I don't care!

 

  • Like 1
Link to review
OguzhanKuyubasi

   2 of 2 members found this review helpful 2 / 2 members

That blows my Mind.

Really Impressive and I thought the Commander X16 isn't capable of running 3D Applications.

  • Like 2
Link to review
scruffy

   2 of 2 members found this review helpful 2 / 2 members

Impressive work

  • Like 1
Link to review
DrTypo

   1 of 1 member found this review helpful 1 / 1 member

Very impressive stuff!

I ported a simple raycasting routine from an existing C routine to x86-64 assembly to see if I could beat the compiler (and I did but not by much).

The thing used quite of lot of floating point math. Nothing a modern x86 CPU can't handle but with the 65c02 you have to be very clever!

Well done!

  • Like 1
Link to review
Yazwho

   1 of 1 member found this review helpful 1 / 1 member

Amazing

  • Like 1
Link to review
AndyMt

   1 of 1 member found this review helpful 1 / 1 member

I'm really impressed with this! It looks very promising, so one day, you might actually achieve a full port of Wolfenstein 3D.

  • Like 1
Link to review
gavinhaslehurst

   1 of 1 member found this review helpful 1 / 1 member

Very cool idea!  Was thinking of doing something like this myself in assembly, but you've beaten me to it 😀

  • Like 1
Link to review

Wow Impressed.
How can this run on a 6502 based machine?

Does it mean it could be ported to good old c64 as well?  Or would the chunky graphics to c64 multicolor bitmap mode conversion be too slow?

Response from the author:

On the forum I explained how this was achieved. The VERA module and the high clock rate of the 6502 in the x16 (8Mhz) make this possible. Its not really possible on a c64.   

Link to review
×
×
  • Create New...

Important Information

Please review our Terms of Use