Final Assault - new game by GMG

[globe]

1 hour ago, danwinslow said:

Just me, but I don't think you should worry about the 64k limit.

That's the plan.

38 minutes ago, Heaven/TQA said:

what "unrolled code" are you using? for tmapping the slices? because the tables itself should be not so ram consuming imho.

If by tmapping the slices you mean scaling and drawing then yes, also lightning pass uses unrolled code (didn't manage to do scaling+drawing and lighting in one pass, not enough registers)

Then there's raycaster itself, while it's not really unrolled code, for speed and simplicity reasons there's code for each quadrant + a lookup table.

 

But the main culprit as far as the RAM consumption goes isn't really the raycasting engine, it's the game itself:

 

Map (both the game map with walls+textures+doors etc.. and the automap which eats about 2,5KB of vram and buffers + some extra for code to generate and show it)

Textures + the code for generating the animated ones on the fly because there's just no space for storing animations in RAM.

Enemy graphics, horizontally pre-scaled so I don't have to waste too much cycles there.

Enemy/item data for new game + the same empty table for the ongoing game.

Enemy behavior code (including line of sight checking which is probably bigger than all relatively simple movement routines together)

Sound effects.

Text messages.

GAME OVER + YOU WON parts

Lots of tables of various sizes for everything else.

 

Most of these you won't need for an engine demo so I can understand you wondering where did all the RAM go but with all that's needed for a game it ads up really fast.

 

6 minutes ago, emkay said:

You must be some "rensoupp" guy to handle this all , and to finalize a game by all this hammering here in the forums. 

Well, I don't really mind the questions and things people notice.

I did take shortcuts and I did sacrifice graphic fidelity and precision for speed and other features.

I can understand that some would prefer to balance things differently but this is the result and, well, there's plenty of people here commenting that could pull off making their own version so maybe this game will motivate someone to do better and we all get more games to play on our favorite hardware.

Also I don't consider this 'hammering', so far the discussion was very civil.

 

[+Stephen]

13 minutes ago, ilmenit said:

Just add Emkay to Ignore List and life will be easier As usually he doesn't understand the issue and has no idea why in case of additionally moving sideways the angle will change and why it should also without moving but only rotating.

So, his vision is as bad as his ears?  It all makes sense now.

[emkay]

Just now, globe said:

 

Also I don't consider this 'hammering', so far the discussion was very civil.

 

It's all just because the game is running already. 

And I'll surely find the time to play through  

[emkay]

3 minutes ago, Stephen said:

So, his vision is as bad as his ears?  It all makes sense now.

So, his vision is as bad as his ears?  It all makes sense now.

[Heaven/TQA]

39 minutes ago, emkay said:

EVERYTHING IS FINE IN THE GAME .

I wrote it in big letters, so you might read it better.

my what??? referred to your comment on rotating angle note.

[ilmenit]

8 minutes ago, globe said:

I did take shortcuts and I did sacrifice graphic fidelity and precision for speed and other features.

I can understand that some would prefer to balance things differently but this is the result and, well, there's plenty of people here commenting that could pull off making their own version so maybe this game will motivate someone to do better and we all get more games to play on our favorite hardware.

I think you did a wonderful job balancing it. Aiming for 64KB machine puts a lot of limitations on the whole development team. Proper 3D projection would require fisheye correction and it requires tables to do it fast (either large ones for fast multiplication or precalculated heights of walls for screen columns) - all eating precious memory. Adding it some other aspects of the game would suffer.

[emkay]

1 minute ago, Heaven/TQA said:

my what??? referred to your comment on rotating angle note.

Look at my gameplay video everything is ok.  

[emkay]

Here a sidewalk demonstration.

It shows how fine the angle calculation is IN THIS GAME .

 

This is far beyond anything on 8 bit computers. 

 

 

 

 

Edited November 3, 2021 by emkay

[Heaven/TQA]

29 minutes ago, globe said:

That's the plan.

If by tmapping the slices you mean scaling and drawing then yes, also lightning pass uses unrolled code (didn't manage to do scaling+drawing and lighting in one pass, not enough registers)

Then there's raycaster itself, while it's not really unrolled code, for speed and simplicity reasons there's code for each quadrant + a lookup table.

 

But the main culprit as far as the RAM consumption goes isn't really the raycasting engine, it's the game itself:

 

Map (both the game map with walls+textures+doors etc.. and the automap which eats about 2,5KB of vram and buffers + some extra for code to generate and show it)

Textures + the code for generating the animated ones on the fly because there's just no space for storing animations in RAM.

Enemy graphics, horizontally pre-scaled so I don't have to waste too much cycles there.

Enemy/item data for new game + the same empty table for the ongoing game.

Enemy behavior code (including line of sight checking which is probably bigger than all relatively simple movement routines together)

Sound effects.

Text messages.

GAME OVER + YOU WON parts

Lots of tables of various sizes for everything else.

 

Most of these you won't need for an engine demo so I can understand you wondering where did all the RAM go but with all that's needed for a game it ads up really fast.

 

Well, I don't really mind the questions and things people notice.

I did take shortcuts and I did sacrifice graphic fidelity and precision for speed and other features.

I can understand that some would prefer to balance things differently but this is the result and, well, there's plenty of people here commenting that could pull off making their own version so maybe this game will motivate someone to do better and we all get more games to play on our favorite hardware.

Also I don't consider this 'hammering', so far the discussion was very civil.

 

Yeah. I was just wondering about the 4-5kb tables... but of course RAM is needed for all those "bits and pieces" to make a game.

[Heaven/TQA]

17 minutes ago, ilmenit said:

I think you did a wonderful job balancing it. Aiming for 64KB machine puts a lot of limitations on the whole development team. Proper 3D projection would require fisheye correction and it requires tables to do it fast (either large ones for fast multiplication or precalculated heights of walls for screen columns) - all eating precious memory. Adding it some other aspects of the game would suffer.

lucky me could use 128kb RAM of the SNES   and the 816 for some 16bit ADCs and the hardware MUL for the raymarching (yeeeah I know wrong term....)

Edited November 3, 2021 by Heaven/TQA

[Heaven/TQA]

18 minutes ago, emkay said:

Look at my gameplay video everything is ok.  

aehm. no... rotating = 2d scrolling.

not to offrail the thread... RoF uses no rotating in X axis... Charly is using "scrolling only" by moving up/down.

Edited November 3, 2021 by Heaven/TQA

[Level42]

1 hour ago, emkay said:

EVERYTHING IS FINE IN THE GAME .

I wrote it in big letters, so you might read it better.

It's funny when Globe, the guy who programmed the game, admits the effect, yet you claim to know it isn't there.....

What a brilliant work this is. Although there have been demo's with similar 3D, here is the first real working game. Didn't have time to try it yet but can't wait. 

I'm absolutely not a programmer but I assume the game takes advantage of Atari's GTIA graphics mode ?

Edited November 3, 2021 by Level42

[emkay]

@globe

1 minute ago, Level42 said:

It's funny when Globe, the guy who programmed the game, admits the effect, yet you claim to know it isn't there.....

It's not visualbe caused by the low resolution. 

You only could ask globe to make the rotation faster, so it will appear what you're missing. 

[emkay]

5 minutes ago, Heaven/TQA said:

aehm. no... rotating = 2d scrolling.

not to offrail the thread... RoF uses no rotating in X axis... Charly is using "scrolling only" by moving up/down.

You're sure, you know things? Sometimes I ask myself how you manage to do those demos. Seems you always used code from others and patched it for your projects. 

Rescue on fratalus is using mode D and plays at around 6 fps. So the jumps in the frames were obvious. 

You guys cannot handle that this game lives by the framerate, not by static pictures. Still the old weirdness... 

[Heaven/TQA]

22 minutes ago, emkay said:

You're sure, you know things? Sometimes I ask myself how you manage to do those demos. Seems you always used code from others and patched it for your projects. 

Rescue on fratalus is using mode D and plays at around 6 fps. So the jumps in the frames were obvious. 

You guys cannot handle that this game lives by the framerate, not by static pictures. Still the old weirdness... 

yes. I know the shit most of the time.  and again you don't get the point... rotating in Y axis is visually not working as you would expect in the game. and same on RoF. but Charly personally told me that he cheated a lot back those days. and RoF uses just small viewport and low Antic D resolution so you dont see the "wrong maths". 

and just for the records me is the last one critizing his approach. his game his time his decision. but me just wondering why. nothing more. and that's why I am asking from coder to coder.

PS: and pointing me to patching others code is like you taking RMTs of others "patching"? Isn't it?

Edited November 3, 2021 by Heaven/TQA

[emkay]

8 minutes ago, Heaven/TQA said:

yes. I know the shit.

But you have no clue about games. 

Watch my videos. Everything is fine.  The closer things move, the more the angle of the walls will change when you were just turning. 

The only thing I miss is the mouse control for turning

Edited November 3, 2021 by emkay

[Heaven/TQA]

9 minutes ago, emkay said:

But you have no clue about games. 

Watch my videos. Everything is fine.  The closer things move, the more the angle of the walls will change when you were just turning. 

The only thing I miss is the mouse control for turning

haha... yeah. I have no clue about games. yes. true. since 80s I have no clue. yup. me just credited at mobygames but yeah.

[emkay]

8 minutes ago, Heaven/TQA said:

haha... yeah. I have no clue about games. yes. true. since 80s I have no clue. yup. me just credited at mobygames but yeah.

Wow, so you created a 3D game with full playability and it looks like on a 386 PC for the stock Atari? 

[Heaven/TQA]

14 minutes ago, emkay said:

Wow, so you created a 3D game with full playability and it looks like on a 386 PC for the stock Atari? 

just my last 2 cents... me was just wondering why the rotating and perspective calculations doesn't meet the expected result. nothing more. I don't played down the afford or the end result. you put me into a corner where I don't belong. and me did working in games biz for years telling me I have no clue about games is like haha... sorry. 

Edited November 3, 2021 by Heaven/TQA

[emkay]

2 minutes ago, Heaven/TQA said:

just my last 2 cents... me was just wondering why the rotating and perspective calculations doesn't meet the expected result. nothing more. I don't played down the afford or the end result. you put me into a corner where I don't belong. and me working in games biz for years telling me I have no clue about games is like haha... sorry. 

People can do fast programs on fast machines. No doubt. 

[flashjazzcat]

https://youtu.be/nHuR5eslKhQ?t=228

 

[Heaven/TQA]

2 minutes ago, emkay said:

People can do fast programs on fast machines. No doubt. 

or on the VIC 20...

[emkay]

3 minutes ago, Heaven/TQA said:

or on the VIC 20...

Remember? This is an Atari 8 Bit Forum. 

[popmilo]

Awesome project, great speed, 99% perfect

 

I would just share this screenshot from video of player strafing made by Emkay:

This is the problem imho. Fisheye not corrected. Wall should be horizontal across the screen width.

Not curved to left and right like red lines show. @globe think you can fix this easily with some math. Even if it's real time multiplication it shouldn't matter much. Drop in fps would probably be torrelable.

 

Thanks for all your effort !

 

[emkay]

1 minute ago, popmilo said:

Awesome project, great speed, 99% perfect

 

I would just share this screenshot from video of player strafing made by Emkay:

This is the problem imho. Fisheye not corrected.

The Fish eye COULD be mentioned. But tell me what you see if you are directly in front of a wall. The more it gets away to the sides, the more the ground or ceiling can be seen. Without that, people might mention that it is just some horizontal scolling ... ?