[16K 3D engine]

6 hours ago, Heaven/TQA said:

what do you mean by "thin walls"?

XXL probably meant something like Capture the flag walls, it's not a raycaster but it has thin walls and despite the grid being only 16x16, the maze can be pretty complicated because of it.

With standard 1 grid square thick walls maze would be much simpler.

 

11 hours ago, xxl said:

Does any of the raycasting engines on the A8 have thin walls implemented?

Not that I know off, but modifying normal raycasting routine for this shouldn't be very complicated.

Map data would need to change though, also texture data if you want to have more than 3.

 

For example we could use bit pairs for 4 walls of a grid square.

00 = no wall, 01 - 11 = texture 1 - 3

Starting from North, going clockwise 00 01 01 01 would get you 'U' shaped 'room' the size of one grid square, all walls using texture 1.

Ray going North East would filter the South walls with AND #%00001100 when going North / up them map, and West walls with AND #%00000011 when going East.

 

Since raycaster detects 'leading edge' of the wall for this to work properly from all angles, adjacent squares would have to have walls 'touching' the walls of our 'U' tile.

So tile to the left would need East wall, tile under North wall etc...

This would also allow for different textures when looking from the inside and from the outside.

[16K 3D engine]

On 2/9/2022 at 1:25 AM, xxl said:

how close can you get to the wall? I ask because small enough allows you to skip collision checking at corners (collision procedure halved)

8 units (player moves over 32x32 grid squares), in Final Assault I didn't check corners at all so you could grind your face right against the wall if you came from the side without triggering the 8 units distance check.

In 128KB engine this is fixed.

[128KB raycaster engine WIP]

4 hours ago, ClausB said:

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

LUT is 5KB. Multiplier is in 1-255 range, multiplicand is always the same 20 values ( cos(angle) part, with angle ranging from 0 to 28.125 in 1.40625 increments)

[16K 3D engine]

6 hours ago, xxl said:

raycaster is for a narrow image (32 bytes) but the pixel width does not have to be in byte size - that's what the renderer is for. It can be 1 pixel (byte width), maybe 2 pixels (as in GR.9), maybe 4 pixels (GR.7) or maybe 8 (GR.8)...

Never really did any calculations but wouldn't bit operations needed for 4 pixels gr.7 or 8 pixels gr.8 cause a relatively big slowdown?

Or is there some clever trick around that?

[128KB raycaster engine WIP]

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.

 

 

[128KB raycaster engine WIP]

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.

 

[128KB raycaster engine WIP]

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

[128KB raycaster engine WIP]

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

[128KB raycaster engine WIP]

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?

 

[128KB raycaster engine WIP]

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.

 

[128KB raycaster engine WIP]

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.

 

[128KB raycaster engine WIP]

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.

 

 

[128KB raycaster engine WIP]

10 hours ago, MrFish said:

I always liked having a key that toggled walk/run (usually <CAPS LOCK>). Funny thing is, I don't ever recall toggling back to walking, in any game.

Might be a good idea to latch fast turning with running -- if you end going for walking + running.

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

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

Binding running together with fast turning might work. I'll do some testing once I have Settings done.

 

7 hours ago, Heaven/TQA said:

what are the texture resolutions?

This version uses 4 'zoom levels'

32x32 = standard size, 64x32 = large size and 16x16 half size together with 8x8 quarter size for smaller wall slices

 

7 hours ago, Heaven/TQA said:

- the frame rate is quite constant which is suprising... as normally it should drop significant when having long corridors... at least on my SNES version

In this map fps may wary between 23 - 33, but the change isn't very abrupt so it's not noticeable I guess.
Also not that many people face-surf the walls which is the only way to get 30+ fps
So in the end we're jumping around +/-3 frames most of the time. (all of this applies to 'full pixels', add +5 frames for black lines mode)

 

Your comment made me curious, so I tried worse case scenario: empty map with walls only along the outer borders, standing in a corner, looking towards the corner across the map.
Got 20fps which was a nice surprise for me, my guess was it's going to be somewhere around 15.

 

7 hours ago, Heaven/TQA said:

all improvements look far better than V1. Kudos! well done.

Thanks. It's much easier with so much extra memory.

128KB v16 faster movement.xex

[128KB raycaster engine WIP]

21 hours ago, MrFish said:

Have you ever considered adding running, using coarse movement too?

Yes, movement needs some rework too.

Not sure yet whether it'll  be just faster walking or walking + running.

[128KB raycaster engine WIP]

11 hours ago, Beeblebrox said:

what is the ANG value all about?  Assume it means angle?? 

Yes, it's player's angle but I left it in hexadecimal for convenience.

Whole 360 degree turn = 128 steps so ANG goes from $00 to $7F.

$00 facing north $20 - east $40 - south, $60 - west

[128KB raycaster engine WIP]

9 hours ago, Beeblebrox said:

I honestly didn't think you would be able to animate the weapons

Just a memory issue, nothing else.

9 hours ago, Beeblebrox said:

 

I get 25fps on full pixel mode and 30fps on every other line is black mode just moving around. When firing the chain gun and moving it drops down to 23 and 28 respectively. The FPS with both is amazing!!!

There's some fluctuation with FPS depending on where you stand.

Wider open ares will go down to 23 while sticking your face closest to the wall will get you 33. Raycasting part has a lot less work in the later scenario so it finishes fast.

Weapon animation shouldn't really affect the frame rate so it's probably the lighting processing that does that.

 

22 minutes ago, pps said:

Just as @ivop wrote. If someone wants to laod from (most) DOS, it won't run. Most DOS block the RAM till around $1F00, so loading below that won't work. Page 6 is free there, too.

Yeah, it's easy to forget this when most of the time I spend in WUDSN + Altirra.

XEX that loads from $2000 is in post #5

[128KB raycaster engine WIP]

16 hours ago, MrFish said:

It doesn't like any Rambo memory config, or the 1088 KB RAM setting.

 

I imagine it's the same problem with running it in Atari800Win PLus too [Edit: verified...].

Looks like I need to read up on various memory upgrades and adjust the bank switching.

 

15 hours ago, TGB1718 said:

I copied both versions onto SIDE 3, used the Loader to run the .XEX's still crashes no matter what

memory config I try, I checked with some games to make sure the SIDE 3 was working and they

loader fine.

Well, try to set Altirra to settings MrFish mentioned in his post above yours.

I'll look into the various memory upgrades and try to come up with something that will work for everyone.

 

EDIT:

Glad you managed to make it work even if it took a while.

 

15 hours ago, MrFish said:

Interestingly, if I start in NTSC and then switch to PAL without restarting, PAL will run @ ~ 30 FPS in full pixel rendering mode (no need switching to every other line rendering mode).

Finally something that's easy to explain:)

Demo only does PAL/NTSC detection at the beginning so if you switch to PAL while it's running, it still counts 60 frames as 1 second instead of 50 and the FPS counter is bloated.

 

11 hours ago, Philsan said:

I think both files need 130XE memory.

Yes, both need 128KB, the only difference is the second file starts loading from higher memory address so it shouldn't overwrite DOS.

[128KB raycaster engine WIP]

18 hours ago, MrFish said:

I'm not able to run it in Altirra (black screen) or Atari800Win PLus (crashes) either.

 

18 hours ago, TGB1718 said:

Nope, nothing seems to work for me, sorry

 

If you don't mind, post your Altirra.ini files, and I'll try to check what's different.

 

Mine's attached but can't be used without some changes because of settings like this: "Kernel path" = "D:\\work\\atari\\wudsn\\Tools\\EMU\\Altirra\\ATARIXL.ROM" that would require editing the path so it points where your Altirra is installed.

 

Tried to run both XEX files in A800Win+ and they work so there must be some config issue.

 

Globe

 

Altirra.ini

[128KB raycaster engine WIP]

20 hours ago, popmilo said:

Nice to see fish-eye corrected !
Good work!

With RAM to spare I just reused the abandoned code from FA.

5KB LUT but walls aren't buckling so worth it.

[128KB raycaster engine WIP]

18 hours ago, TGB1718 said:

Nope, nothing seems to work for me, sorry

I get the first XEX loading low won't work,  but no idea why the 'fixed' one starting at $2000 won't, hard to debug when it works here.

I'll try to make one more xex starting even higher when I have time.

[128KB raycaster engine WIP]

8 minutes ago, TGB1718 said:

Was using Altirra, loading DOS on D1:, your file from D4:

Try ALT+B or through menu File -> Boot Image and pick the XEX (xex switches off Basic, no need to do it manually)

I have Altirra set to PAL 130XE with firmware ATARI XL/XE OS ver.2

[128KB raycaster engine WIP]

18 minutes ago, TGB1718 said:

I've even tried a stock 130XE, BASIC disabled and it still crashes

That's strange. What device did you use for loading?

I tested with AVG cart and SIDE3 and both worked on stock 130XE.

[128KB raycaster engine WIP]

58 minutes ago, TGB1718 said:

Can't get it to run, 130XE, U1M, SIDE3 says Memory Conflict even with the 'X' before the command.

 

Disabled SDX and booted a SDX floppy , system crashed immediately.

I don't have U1M yet so I can't test on real HW, but I read couple of posts mentioning XEX files loading too low getting 'memory conflict' error (this one starts loading from $0f00) so I rearranged some stuff and now it's loading from $2000.

Let's see if that helps.

mem conflict v16.xex

[128KB raycaster engine WIP]

Finally got some time this weekend to finish the preview for 128KB raycaster engine.

 

features:

-resolution: 80x48

-fish eye correction

-proper wall slice scaling

-fully adjustable controls

-reworked weapons with (very) short animations

 

1. pick one of control presets or define custom controls

 

2. press ESC for 'game' (there's no game yet but you can walk around, switch weapons and shoot)

 

3. press START+SELECT+OPTION to switch between 'full' pixels and 'every other line is black' mode (there's roughly +5 fps gain with the later)

4. press START+SELECT+OPTION+some key to get back to Controls setup screen

 

This is early work in progress so a lot of stuff just isn't there yet.

 

It's both a preview and new controls test so if you find something not working properly as far as controls are concerned let me know.

One feature that is missing is Settings screen so for now the fast turning has fixed speed, but in later versions it will be user-adjustable, also it will be possible to set fast turning as default.

Other features in Setting screen will include weapon bobbing toggle, cross hair toggle, floor/ceiling presets + customization and more.

 

Globe/GMG

 

ps: It's probably clear from the title but the .XEX will only work on Atari 130XE and compatible with 128KB RAM or more.

eng128 v16.xex

[Final Assault - new game by GMG]

23 hours ago, Beeblebrox said:

Honestly it makes such a huge difference to the gameplay!

Definitely. All the available buttons make a difference.

 

23 hours ago, Beeblebrox said:

 

@globe  There is one button on the SNES (green Y button) that isn't used for anything in FA currently - a pause button jumps to mind - being able to pause the game would be great.  I guess some might say it'll quite possibly take the tension out of gameplay if at a nerve wracking moment you could potentially pause to collect thoughts (or make a cuppa coffee) - but I still think it could be helpful.

 

Edit: Alternatively Y could be used to cycle through the weapon select the other way - so B cycles right through weapons selection, and Y cycles left. Just a thought.

If for some reason FA 1.2 happens I'll consider it.

 

23 hours ago, Beeblebrox said:

Gonna have a proper FA session later this weekend as well as testing other games with the joypad, but just wanted to let ya'll know IMHO it's literally a game changer, especially for FPS engines   I really hope we see more FPS raycasting games on the A8 in months and years to come, all taking advantage of joypads.

Don't worry, after all the work I'm going to milk it for a while :):):)

 

I still want to make a big game that will be similar to System Shock with several floors, player augments, computer hacking, progress saving etc...

But that's far into the future.

Currently focusing on 128KB engine, hopefully I'll have something to show in a couple of weeks.

 

11 hours ago, Poison said:

It would be great to add modern ST mouse control  RMB for Fire and for rotate. And keys WSAD for move  A,D strafe L/R, W front, S back . .

As far as controls are concerned I added some options to 128KB engine and support for multiple controllers, but I'm kind of torn on the mouse controls.

Since this kind of engine doesn't support looking up and down (well, it's technically possible to fake but not sure the cost is worth it for mostly cosmetic feature) it would be limited to turning and shooting.

Also I vaguely remember reading somewhere that you have to mod your mouse for the RMB to work.

WSAD controls are possible as long as you don't want to strafe while also moving forward or backward - keyboard limitations.

 

Here's a peek of what's coming:

 

There are a few control presets for various controllers + Custom preset that player can freely edit.

Currently supported controllers: Joystick, Joy2B+ with one or two extra buttons, SNACK in Classic or Enhanced mode, Atari Video Touch Pad (+similar) keypads and most of the keyboard.