128KB raycaster engine WIP

[+MrFish]

56 minutes ago, globe said:

For now try this out, movement is roughly twice as fast.

It looks good. The visuals are a little jerky -- as expected -- but not much. I'm wondering if speeding it up even more might make the jerkiness less noticeable; plus I think it would be interesting to see what various higher speeds would yield.

  

56 minutes ago, globe said:

Toggling is possible but I'd like to keep the number of buttons to necessary minimum because there's so many of them already.

You can never have too many keys in an FPS.

 

[Heaven/TQA]

Ok. Can you explain why you use different texture sizes? Doesn't make it complicated? Or is it kind of mip mapping?

 

And the extra ram is used for the tables and textures and unrolled code?

[globe]

21 hours ago, MrFish said:

I'm wondering if speeding it up even more might make the jerkiness less noticeable; plus I think it would be interesting to see what various higher speeds would yield.

Currently walking speed is at '6' meaning you need roughly 5 steps to make it across one map tile (one tile = 32x32 points player can stand on).

Strafing uses speed 4.

I'll make some user-adjustable version for testing over the weekend.

 

21 hours ago, MrFish said:

You can never have too many keys in an FPS.

 

Well, you can always glue 2 SNACKs together

 

9 hours ago, Heaven/TQA said:

Ok. Can you explain why you use different texture sizes? Doesn't make it complicated? Or is it kind of mip mapping?

The big one 64x32 is there to solve this:

 

 

Once you get close enough that few rays hit the same wall slice the texture gets stretched horizontally like this and it's not pretty.

 

Compared to new engine:

 

 

Nice fat pixels without the stretched line patterns.

 

The half sized and quarter sized textures should make the texture easier to recognize when walls are farther and wall slices are smaller.

Works better for some textures, worse for others, any finer details tend to vanish pretty fast anyway because of the low resolution.

 

It's not really complicated since the appropriate textures are picked by unrolled drawing routine (which is gigantic now, 10,5KB compared to 4 pages Final Assault used)

 

9 hours ago, Heaven/TQA said:

And the extra ram is used for the tables and textures and unrolled code?

Bank 3 is full of LUTs for raycaster.

Bank 2 is 30% full - there's Controls setup and I plan to stick whole Options + main screen etc.. there

Bank 1 and 0 are currently empty but this is far from finished.

 

 

[+MrFish]

2 hours ago, globe said:

I'll make some user-adjustable version for testing over the weekend.

That'll be good.

 

2 hours ago, globe said:

Well, you can always glue 2 SNACKs together

Yeah, I usually have an assortment of snacks piled together while I'm gaming...

 

My preferred controller setup for FPS games (on a PC) is...

Mouse (right hand): for turn left/right, look up/down, fire weapon #1 & #2 with left and right buttons, mousewheel for selecting weapons, and wheel-button for scope zooming.

Keyboard (left hand): foward/back with up/down arrow keys, strafe left/right with left/right arrow keys.

Then any other often-used functions (jump, crouch...) are as close to my pinky (right <ctrl>, right <shft>, <enter>) and thumb (numpad) as possible.

Any remaining function go on the Home, Pg Up, Pg Down, End, etc. and/or the numpad areas of the keyboard.

 

Obviously this all goes out the window with a real Atari -- unless I've got a PC keyboard hooked up to it or using emulation; then I've got that part of the layout (but no mouse).

Most Atari mice (ST or modified Amiga) are a non-starter, as there's too much overhead (gray code attention). Something like @Irgendwer's mouse interface -- that can use paddle, driving controller, or touch tablet input -- would be more ideal.

 

On a real Atari, I'd probably prefer straight-up 100% keyboard input (haven't played it on real hardware yet, unfortunately). I have never liked any type of joystick/controller (analogue or digital) on modern systems for FPS games. There is no replacement for the smooth turning and up and down looking that can be had from a mouse, and the way that can be combined with keyboard arrow-key movement, in my experience.

 

[globe]

19 minutes ago, MrFish said:

Most Atari mice (ST or modified Amiga) are a non-starter, as there's too much overhead (gray code attention). Something like @Irgendwer's mouse interface -- that can use paddle, driving controller, or touch tablet input -- would be possible.

Got my hands on ST mouse so I'm going to try this: https://atariwiki.org/wiki/Wiki.jsp?page=Ironman Atari#section-Ironman+Atari-UsingTheMouse

Looks simple and fast, runs in VBI, no idea whether it will be suitable for looking around but I'll find out sooner or later (too many things I want to test are waiting already and there's too little free time)

24 minutes ago, MrFish said:

On a real Atari, I'd probably prefer straight-up 100% keyboard input (haven't played it on real hardware yet, unfortunately). I have never liked any type of joystick/controller (analogue or digital) on modern systems for FPS games. There is no replacement for the smooth turning and up and down looking that can be had from a mouse, and the way that can be combined with keyboard arrow-key movement, in my experience.

In emulator I prefer keyboard. Too bad there's 1 key press limit for most of it on real HW. Joystick isn't very well suited for this, but gamepad is a nice compromise once you get used to it, plenty of buttons and almost no limits for simultaneous button presses. I game both on PC and consoles so it didn't take me that long to adapt.

 

[_The Doctor__]

but the Atari can use combos of shft + key, cntrol + key, shift control +key, console, console plus key, and other varied combinations.... certainly more than one way to skin any key cat...

[+MrFish]

6 minutes ago, globe said:

Got my hands on ST mouse so I'm going to try this: https://atariwiki.org/wiki/Wiki.jsp?page=Ironman Atari#section-Ironman+Atari-UsingTheMouse

Looks simple and fast, runs in VBI, no idea whether it will be suitable for looking around but I'll find out sooner or later (too many things I want to test are waiting already and there's too little free time)

Yeah, I guess that's on you to know whether it could fit into your system/game. The main thing about gray-code interpretation on the Atari is to prevent movement from getting ahead of reads. Generally, if the driver is designed to be sensitive enough to small movements, wherein the mouse doesn't need to be moved much to produce movement on the screen, then things work out. If the mouse needs to be moved a lot for a small amount of movement on screen, then things can start to get out of hand.

 

Part of this is down to the sampling rate. @flashjazzcat (in the 8-bit GUI) resorted to using DLI's to get a higher sampling rate than the typical VBI routine. So, you may want to look into something like that.

  

6 minutes ago, globe said:

In emulator I prefer keyboard. Too bad there's 1 key press limit for most of it on real HW. Joystick isn't very well suited for this, but gamepad is a nice compromise once you get used to it, plenty of buttons and almost no limits for simultaneous button presses. I game both on PC and consoles so it didn't take me that long to adapt.

I'd be interested to try the gamepad, but the main problem is that the left/right turning is either on or off, and thus feels unnatural compared with a mouse. It's like in Pole Position, where a joystick is used for turning, instead of a steering wheel or any potentiometer-based controller. You end up to this tap, tap, tap left... tap, tap, tap, right. It can be accommodated; but it's not optimal, especially when other solutions are readily available.

 

[globe]

17 minutes ago, _The Doctor__ said:

but the Atari can use combos of shft + key, cntrol + key, shift control +key, console, console plus key, and other varied combinations....

Shift + console keys are good, they can be all pressed simultaneously, detected individually and combined with 'normal' keys.

FA already used console keys + shift for controls and this engine does too.

Control is more of a problem since it can't be detected on it's own only with other key pressed.

Keyboard controls are not impossible, players just have to pick the keys carefully so the controls triggered simultaneously would work.

 

6 minutes ago, MrFish said:

 

Part of this is down to the sampling rate. @flashjazzcat (in the 8-bit GUI) resorted to using DLI's to get a higher sampling rate than the typical VBI routine. So, you may want to look into something like that.

Thanks, I'll look into it.

 

[flashjazzcat]

I'll have to look again at that routine. It seems familiar: I remember the bit about periodic re-synchronisation being required.

 

 

 

[shanti77]

Great job @globe!
I have been tinkering for some time (in my spare time) with a similar engine.
Screen size in 31x64 bytes, one texture size 16x64 bytes (32x64 pixels), it causes poor horizontal scaling (but it will be better). Map size 128x128 tiles, works on Atari130xe. Weak textures because drawn with dta b (xx).
The door can be opened with the second fire (if you do not have a second fire, it opens by itself when you approach them), there are only 2 doors, both are closed with the SHIFT key. I have added 1 item (key) for testing, it cannot be collected yet.
Fire + Left / Right = move left / right.
A = Angle from $ 00 to $ ff (0 to 359 degrees)
F = 1 screen drawing time counted in frames, i.e. fps = 50 / F (1.0 = 50fps, 2.0 = 25fps)

 

Select=on/off interlaced mode

w.xex

Edited February 4, 2022 by shanti77

[globe]

8 hours ago, shanti77 said:

Great job @globe!
I have been tinkering for some time (in my spare time) with a similar engine.
Screen size in 31x64 bytes, one texture size 16x64 bytes (32x64 pixels), it causes poor horizontal scaling (but it will be better). Map size 128x128 tiles, works on Atari130xe. Weak textures because drawn with dta b (xx).
The door can be opened with the second fire (if you do not have a second fire, it opens by itself when you approach them), there are only 2 doors, both are closed with the SHIFT key. I have added 1 item (key) for testing, it cannot be collected yet.

Thank you.

Your engine looks great!

Colors make it easy to distinguish between 'face' walls and side walls.

Map size is really impressive and also the speed when handling big open spaces (so far I'm still stuck with 16 x 16 tiles map segments connected into bigger map, though I have couple of ideas how to make bigger maps without slowing down the raycaster too much)

Do you use some length limit for rays so there's not a big slowdown with open spaces?

 

Also the door handling is great. Doors and half height walls are on my to do list, didn't manage to cram them into 64KB engine but they will be in 128KB version.

 

If you don't mind me asking, why 31 bytes horizontally, why not 32?

 

[shanti77]

@globe

Of course, the rays have a length limit, as can be seen from the slowly emerging faces.

 

If the beam hits the door, it checks the condition of the door. If they are closed it stops, if it is open it keeps going. In the event that the door is being opened, you need to check which part of the door it hit and, based on that, either stop it or let it go.

The screen is 31 bytes wide, because I use a trick to speed up the calculations. I shoot every other ray, which is 31,29,27 ... 3,1. Now, for example, if radius 1 and 3 hit the same tile, I assume that radius 2 must also hit it. It is enough to calculate the length of the beam as the average of the lengths of rays 1 and 3. It also helps in open spaces, because if rays 1 and 3 did not hit anything, then 2 would not hit anything. Of course, if rays 1 and 3 hit different tiles, radius 2 must be checked.

[globe]

20 minutes ago, shanti77 said:

Of course, the rays have a length limit, as can be seen from the slowly emerging faces.

Wrong question I guess, what I wanted to ask is how many tiles do you check till you stop?

 

When I was considering what kind of map to use for Final Assault I ended up with the map cut into smaller segments because it made the map lookup faster and enemy and item handling much easier (only active segment was handled 4 enemies max / 4 items max, rest was 'frozen' till player got there).

I have no clear idea how I'd handle that on one giant map.

 

34 minutes ago, shanti77 said:

The screen is 31 bytes wide, because I use a trick to speed up the calculations. I shoot every other ray, which is 31,29,27 ... 3,1. Now, for example, if radius 1 and 3 hit the same tile, I assume that radius 2 must also hit it. It is enough to calculate the length of the beam as the average of the lengths of rays 1 and 3. It also helps in open spaces, because if rays 1 and 3 did not hit anything, then 2 would not hit anything. Of course, if rays 1 and 3 hit different tiles, radius 2 must be checked.

Nice optimization, looking at the tiles that get hit twice or more times, this could save a plenty of cycles.

 

On 2/3/2022 at 6:44 PM, MrFish said:

It looks good. The visuals are a little jerky -- as expected -- but not much. I'm wondering if speeding it up even more might make the jerkiness less noticeable; plus I think it would be interesting to see what various higher speeds would yield.

Here's the adjustable step length version.

Increasing and decreasing are tied to currently unused controls for USE and MAP.

MAP = increase step length ( 'space' in first controls preset)

USE = decrease step length ( 'z' in first controls preset)

 

For strafing I subtract 2 for a slower movement sideways.

 

Upper limit is 64 but that's basically skipping 2 map tiles in one step.

To me it looks like anything bigger than 8 is too fast.

 

 

 

 

 

 

128KB v16 movement speed controls.xex

[ClausB]

What kind of multiplication routine do you use, regular shift and add, or quarter square LUT?

[emkay]

I wonder, how much changes had to be done, to make some racing game out of it.

Thinking of some textured tunnel, driving faster and slower, Some floor some sky... 

[+MrFish]

6 hours ago, globe said:

Here's the adjustable step length version.

Increasing and decreasing are tied to currently unused controls for USE and MAP.

MAP = increase step length ( 'space' in first controls preset)

USE = decrease step length ( 'z' in first controls preset)

 

For strafing I subtract 2 for a slower movement sideways.

 

Upper limit is 64 but that's basically skipping 2 map tiles in one step.

To me it looks like anything bigger than 8 is too fast.

 

Crap! The higher speeds look great! Turning definitely needs to be scaled to match each of the forward movement speeds, though.

 

I actually think it would be great to have some variable speed for movement as a regular part of the game too. I mean, think about it: I can move at any speed I choose (within limits) in real life.

 

[+MrFish]

2 hours ago, emkay said:

I wonder, how much changes had to be done, to make some racing game out of it.

Thinking of some textured tunnel, driving faster and slower, Some floor some sky... 

The higher speeds open up a world of possibilities.

 

Why in the world hasn't anybody tried playing with movement granularity in 3D engines like this before?? If they have, I certainly haven't seen it. It seems like everybody is fixated on smooth movement only...

 

[+MrFish]

7 hours ago, globe said:

To me it looks like anything bigger than 8 is too fast.

Yes, 8 seems like a good upper limit for running.

 

[globe]

23 hours ago, ClausB said:

What kind of multiplication routine do you use, regular shift and add, or quarter square LUT?

LUT lookup, as it's fastest even if it eats up RAM.

 

22 hours ago, emkay said:

I wonder, how much changes had to be done, to make some racing game out of it.

Thinking of some textured tunnel, driving faster and slower, Some floor some sky... 

Textured tunnel with speed changes wouldn't take a lot of work, floor would be a problem, proper rotating floor would slow things down a lot, skyline shouldn't be much of a problem.

Besides the floor the the main trouble is that walls are always in a square grid so the curves would look 'blocky'.

19 hours ago, MrFish said:

Crap! The higher speeds look great! Turning definitely needs to be scaled to match each of the forward movement speeds, though.

 

I actually think it would be great to have some variable speed for movement as a regular part of the game too. I mean, think about it: I can move at any speed I choose (within limits) in real life.

 

Ok, I'll change 'Turn speed' button to 'Speed' button and it will affect both turning speed and movement speed.

For starters let's try walking speed 4 and running 8 and see haw that goes.

Fast turning was going to be user adjustable anyway so players can pick what works for them.

 

Edit:

Attached version now has working SPEED button and adjustable turn rate (tied to same controls as before, so MAP = increase turn rate = 'space' in 1st preset and USE = decrease turn rate = 'z')

 

Whole 360 degrees turn has 128 steps so any higher turn rate will look very jerky.

Later when Options screen is done there will be extra options for high rate/snap turning so it's easier to use.

 

Edit2:

 

Bug in xex

 

128KB v17 fixed.xex

Edited February 6, 2022 by globe
Bug in xex

[Beeblebrox]

4 hours ago, globe said:

 

Ok, I'll change 'Turn speed' button to 'Speed' button and it will affect both turning speed and movement speed.

For starters let's try walking speed 4 and running 8 and see haw that goes.

Fast turning was going to be user adjustable anyway so players can pick what works for them.

 

Edit:

Attached version now has working SPEED button and adjustable turn rate (tied to same controls as before, so MAP = increase turn rate = 'space' in 1st preset and USE = decrease turn rate = 'z')

 

Whole 360 degrees turn has 128 steps so any higher turn rate will look very jerky.

Later when Options screen is done there will be extra options for high rate/snap turning so it's easier to use.

 

128KB v17 move+turn speed button.xex 62.33 kB · 1 download

@globe  Great work on this.

 

Just to say I've had no luck running this modified version above (128KB v17 move+turn speed button.xex), when using my SNACK enhanced mode adapter, on either my stock 130XE or my 800XL with U1MB running in 576KB compyshop mode. It throws up frozen garbage on screen after exiting the menu, where you can see part of the playfield behind the garbage on my Stock 130XE, and total garbage when running off my 800XL (576KB Compyshop mode). If you don't enable SNACK and just go straight into the game with default control settings (joystick and keyboard) it is ok and plays fine.

 

See images below.

 

So for the record previous version, (eng128 v16.xex), works on both the above machines with the SNACK adapter in enhanced mode.

 

Any ideas why enabliing SNACK enhanced mode in this new v17 crashes the main game screen?

 

Anyways I tested the new fast turn with the default control settings using the shift key and it's fantastic and spot on at the default turn rate of 8! Very smooth both when moving and when moving and firing. Running around is fantastic too and totally controllable. Great work. Such a relatively simple addition but will be sure to enhance the engine.

Still can't believe we are getting such fast and fluid movement and scaling in walking mode, let alone running, on an A8!

 

Truely amazing work!

 

130XE garbage when SNACK enhanced mode enabled at the menu and game demo started:

 

 

and the 800XL (U1MB running in 576KB Compyshop mode):

Edited February 6, 2022 by Beeblebrox

[globe]

23 minutes ago, Beeblebrox said:

ust to say I've had no luck running this modified version above (128KB v17 move+turn speed button.xex), when using my SNACK enhanced mode adapter, on either my stock 130XE or my 800XL with U1MB running in 576KB compyshop mode. It throws up frozen garbage on screen after exiting the menu, where you can see part of the playfield behind the garbage on my Stock 130XE, and total garbage when running off my 800XL (576KB Compyshop mode). If you don't enable SNACK and just go straight into the game with default control settings (joystick and keyboard) it is ok and plays fine.

 

See images below.

 

So for the record previous version, (eng128 v16.xex), works on both the above machines with the SNACK adapter in enhanced mode.

 

Any ideas why enabliing SNACK enhanced mode in this new v17 crashes the main game screen?

Thanks for the report, it was a small update so I didn't test properly and there was a bug in increase/decrease turn rate controls when those were mapped to controller other than keyboard.

Fixed xex in post above.

 

Also thanks for testing, I'm glad the changes in controls worked as intended.

 

[Beeblebrox]

@globe ah cool  -great - I'll try that. 

 

EDIT: works fine with the fixed V17 XEX on both my machines in question with the SNACK adapter in enhanced mode.

 

Amazing to be able to pick up the pace and run or quickly turn around at the touch of a button. Adds a new dynamic to the gameplay. 

 

Keep up the good work and thanks again.

Edited February 6, 2022 by Beeblebrox

[ClausB]

8 hours ago, globe said:

LUT lookup, as it's fastest even if it eats up RAM.

Quarter square LUT needs only 1K for 8x8->16 bits.

[globe]

1 hour ago, ClausB said:

Quarter square LUT needs only 1K for 8x8->16 bits.

Sure that would save few KB but how fast is it?

Simple lookup is constant 12 cycles.

There are 40 multiplications needed for the fish eye correction ( corrected_distance = ray_length * cos (angle) ) for one frame.

At 25fps that's 1000 multiplications / sec = 12000 cycles = roughly 1/3 of PAL frame spent on multiplication every second.

 

I checked some fast routines on codebase64.org (they have routines using Quarter square LUTs too) and the ones with listed speeds spent average 70 - 100 cycles per multiplication.

Now add some cycles for fixing the decimal point and we're easily down 2 or 3 frames.

 

 

[ClausB]

8 hours ago, globe said:

constant 12 cycles

Nice! Are you doing signed 8x8->8 bits? So a 64K LUT?