Jump to content

Jeffrey

Members
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

29 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks. Its a lot of fun doing it! Yeah. Right now I estimate that a speed of 10-15 fps is achievable with a resolution of 304x152 pixels for the 3D-rendering part, which is the resolution the original Wolfenstein 3D shareware version had (the NTSC version). The PAL version has vertical 182 pixels. When you want more than 15 fps the most effective way to do that (I think) would be to scale in width: making the vertical bars look like 4 pixels wide (instead of 1). It's only a quarter of the work and would likely do the trick (achieving 50-60 fps). And might still be nice to look at. The sprites might look weird though. Not sure. Currently I am handwriting the ray-casting routines (DDA) in assembly. Quite hard and time consuming. Because that is now the bottleneck. If that works we'll see what kind of speed comes out of that. Of course all of the above does not factor in the game itself, just the engine. So it will probably be a bit slower. But the goal of this demo is to see if a raycasting engine is achievable at reasonable speeds on the X16. Having fun just thinking about this problem! PS. earlier I was thinking of using 100+ sprites and showing them multiple times in a single frame (like I did in the vertical bar scroller) which would effectively create around 500 sprites on screen and then placing those sprites very carefully on the screen so 4 of them (stacked vertically) would effectively create a verticall bar (with a texture) that would represent a cast ray and would be 3 or 4 pixels wide. That would me much faster (than blitting to the screen), but I've abandoned that idea because it doesn't seem to work with multiple textures.
  2. Indeed. Thats where I got the idea from. The above mentioned video says: "As there is only a finite number of possible heights, Wolfenstein code generates one routine for every possible height". Right now I store the textures in VRAM. When I generate such a routine its simply looks something like this: In that example it writes about 2-3 times more to the screen than it reads from the texture (which is 64x64 pixels). The nice thing about VERA is that you can do this vertically, which suits drawing columns for each ray very well. This takes less than 8 cycles per pixel. Sometimes you read more than you write (when walls are smaller than the textures). Sometimes you write more than you read (when the walls are taller than the texture). All in all a little less than 8 cycles. I still need to optimize the smaller walls (as they dummy-load too much right now, so I probably need a secondary, smaller texture or double my stride). For the ceiling and floor I simply have a single routine with a whole bunch to STA VERA_DATA0's and I jump in that routine at exactly the right place (with the correct color in A). So those take only 4 cycles per pixel. I can still speed that up a little by remembering how tall the wall (on that column) was the previous frame, so I only have to remove that old wall and not redraw the entire ceiling or floor. Fun stuff!
  3. Thanks! Yes I already saw his video. In fact I am subscribed to his channel . He always creates very instructive videos about how to do things from scratch. He is an inspiration. For this topic he refers to this blog: https://lodev.org/cgtutor/raycasting.html That technique however uses a somewhat diffrerent technique than the original Wolfenstein did: the original technique is (I think, but I could be wrong) better suited if you only have 8-16 bit fixed point numbers (and not floating point numbers). Here is a video about the original Wolfenstein 3D technique that was very useful to me: It's fascinating when diving into this stuff: how brilliant John Carmack was to figure this stuff out by himself in those days. Regards, Jeffrey PS. In order to speed up drawing (massively) I am now also generating "hardcoded" machine code for drawing each possible wall-height. Pretty crazy, but it really works well .
  4. Trying to draw some textures: This is just in PoC now. Its very slow. But I now know how to make it work in principle. Now I somehow have to make this perform...
  5. Jeffrey

    Little Intro

    Very cool and smooth!
    Very cool. My guess is you are moving the sprites using line interrupts (a bit like I did in my vertical bar scroller demo). I didn't think you could move that many though. Well done!! Can you explain how you did it? Regards, Jeffrey Edit: Ah. I can see the source now.
  6. I just uploaded a new version of the raycaster. Nice colors and quite a lot faster now: This is more fun than I had imagined.
  7. Hi! I am from the Netherlands. My background is in electronics and software engineering (AI). I currently work for a train company as a developer. My first computer I saw in real live - and then programmed on endlessly (in BASIC) - was a C64. Very good memories of that. And our first computer at home was an Amiga 500. I love the idea of being constraint by certain limits and embracing those contraints: it inspires me to find creative solutions that I normally would never thought of. The x16 project has triggered that strong feeling in me again. Right now I am working on a raycaster for the x16 and I am having a lot of fun with it: If that goes well I might begin porting/recreating the game "Wolfenstein 3D" to the x16. I am not sure if that is possible, but that is exactly the kind of challenge I like. Regards, Jeffrey
  8. Hi, Right now sending bytes to VERA takes 4 cycles, like this: STA $9F23 As far as I know there is no faster way to send data to VERA right now. But if you could make DATA0 (and DATA1) available as zero page addresses you would make sending data to VERA 25% faster, like this (the address $70 is just an example) : STA $70 That would take only 3 cycles. This is especially noticable when drawing many pixels of the same colour (for example textureless polygons for 3D rendering). I dont know exactly what it would take from a hardware perspective, probably some logic to select/enable the VERA data port based on the specific address bus lines. If its not too hard it would likely pay off quite significantly. Regards, Jeffrey
  9. Version 1.0.0

    10 downloads

    This is a demo to try out how far VERA can be pushed: it is quite hard to have vertically (independently) scolling bars using VERA. What this demonstrates is that it is in possible. But only just. It turns out I had to use 80 sprites in combination with a lot of LINE-interrupts. Here is what I did: - Create a 64 pixel by 5*64 pixel colored data rectangle (in this example filled with 4x4 pixel squares) - Place 80 sprites (of 64x64 pixels) from left to right, overlapping mostly, but showing the 4 left pixels of each sprite - These sprites are (vertically) grouped in pairs, so that each pair is placed one pixel lower than the pair next to it on the right - The data address of each sprite (where they get their colored pixels from) are initially set to the same point (they all start with an vertical offset of 0) - For each low-res LINE-interrupt (that is: 240 times per frame) we do the following: - move one pair of sprites (that are *just* out of view) 64 pixels down - change the data address so that it matches it individual vertical-offset - At the end of all the LINE-interrups (after the 240 lines) we do the following: - Adjust the vertical offsets with the individual change-per-frame numbers - Move all sprites back to the top, with negative y-coordinates (according to their offsets) It runs a maximum fps: every frame there is an update. Warning: this demo contains (what amounts to) flashing / strobing effects. # Known issues - There are small horizontal lines visible at certain places. This is probably because the LINE-interrupt code is not fast enough # Comparing hardware with emulator I think this demo will probably not work (exactly) the same on real hardware. It's probably a good way to check whether the emulator is accurate (for certain aspects of the VERA board). # To Compile: cl65 -t cx16 -o VBS.PRG -l vbs.list vbs.asm # To Run: x16emu.exe -prg VBS.PRG -run Regards, Jeffrey
  10. Vertical Bar Scroller View File This is a demo to try out how far VERA can be pushed: it is quite hard to have vertically (independently) scolling bars using VERA. What this demonstrates is that it is in possible. But only just. It turns out I had to use 80 sprites in combination with a lot of LINE-interrupts. Here is what I did: - Create a 64 pixel by 5*64 pixel colored data rectangle (in this example filled with 4x4 pixel squares) - Place 80 sprites (of 64x64 pixels) from left to right, overlapping mostly, but showing the 4 left pixels of each sprite - These sprites are (vertically) grouped in pairs, so that each pair is placed one pixel lower than the pair next to it on the right - The data address of each sprite (where they get their colored pixels from) are initially set to the same point (they all start with an vertical offset of 0) - For each low-res LINE-interrupt (that is: 240 times per frame) we do the following: - move one pair of sprites (that are *just* out of view) 64 pixels down - change the data address so that it matches it individual vertical-offset - At the end of all the LINE-interrups (after the 240 lines) we do the following: - Adjust the vertical offsets with the individual change-per-frame numbers - Move all sprites back to the top, with negative y-coordinates (according to their offsets) It runs a maximum fps: every frame there is an update. Warning: this demo contains (what amounts to) flashing / strobing effects. # Known issues - There are small horizontal lines visible at certain places. This is probably because the LINE-interrupt code is not fast enough # Comparing hardware with emulator I think this demo will probably not work (exactly) the same on real hardware. It's probably a good way to check whether the emulator is accurate (for certain aspects of the VERA board). # To Compile: cl65 -t cx16 -o VBS.PRG -l vbs.list vbs.asm # To Run: x16emu.exe -prg VBS.PRG -run Regards, Jeffrey Submitter Jeffrey Submitted 02/24/21 Category Demos  
  11. Version 1.1.0

    62 downloads

    # Raycaster demo (written in c) The raycaster has been improved quite a bit. See below description of version 1.1.0 This is a raycaster demo written in c 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! New in this version 1.1.0: - Much improved DDA casting algoritm (speed increase). - Collision detection (you can't walk through walls anymore) - Smoother walls (much less jaggy) - Ceiling and floor added - Colors added to walls - Bigger map - Strafing added: you can use a,d,w,s for moving, q,e for turning (see usage below) - Added simple title screen - Debug mode / tooling # In the previous version 1.0.0: - Using a 'naive' raycasting technique (=slow and jaggy lines) - Only grey colors # Usage To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG -l ray.list ray.c To run: x16emu.exe -prg RAY.PRG -run To play: w - move forwards s - move backwards a - strafe left d - strafe right q - turn left e - turn 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.1.0) - Sometimes you get a "blue screen of death", because a ray cast is in an infinite loop. Please send a screenshot if this happens to you. # Next up: - I would like to port some of the performance critical functions towards assembly. Most notably the DDA casting algo itself and the drawing routines. - Add a time-per-frame indicator (using a vsync interrupt counter) - Show a map on the screen - Add textures - Add Sprites - Add a border around the screen and some player stats/info at the bottom (like Wolfenstein 3D) Having fun! Jeffrey
  12. Raycasting demo (written in c) View File # Raycaster demo (written in c) The raycaster has been improved quite a bit. See below description of version 1.1.0 This is a raycaster demo written in c 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! New in this version 1.1.0: - Much improved DDA casting algoritm (speed increase). - Collision detection (you can't walk through walls anymore) - Smoother walls (much less jaggy) - Ceiling and floor added - Colors added to walls - Bigger map - Strafing added: you can use a,d,w,s for moving, q,e for turning (see usage below) - Added simple title screen - Debug mode / tooling # In the previous version 1.0.0: - Using a 'naive' raycasting technique (=slow and jaggy lines) - Only grey colors # Usage To compile: (this assumes cc65 is installed) cl65 -t cx16 -o RAY.PRG -l ray.list ray.c To run: x16emu.exe -prg RAY.PRG -run To play: w - move forwards s - move backwards a - strafe left d - strafe right q - turn left e - turn 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.1.0) - Sometimes you get a "blue screen of death", because a ray cast is in an infinite loop. Please send a screenshot if this happens to you. # Next up: - I would like to port some of the performance critical functions towards assembly. Most notably the DDA casting algo itself and the drawing routines. - Add a time-per-frame indicator (using a vsync interrupt counter) - Show a map on the screen - Add textures - Add Sprites - Add a border around the screen and some player stats/info at the bottom (like Wolfenstein 3D) Having fun! Jeffrey Submitter Jeffrey Submitted 02/19/21 Category Demos  
×
×
  • Create New...

Important Information

Please review our Terms of Use