BattleZone for Oric: suspended due to deep disgust of lead (and sole) developer

[jbperin]

I recently attempted to resume development of an old idea that I had to create a clone of BattleZone for Oric atmos computer.

I decided to create a prototype which:
- adapts the screen layout to better match Atmos capabilities (radar is located at the bottom of the screen rather than in the upper part)
- contains animated 3d object in the scene and allows to throw missiles to enemies (as I did in this attempt)
- benefits of the overlay memory (no rom function used)
- embed the powerful rax's h3 canvas to display the radar.

I was about to add:
- a collision detection to generate explosion
- possibility to move the point of view (as in the real game)

But I suddenly realized that I had a strong impeachment: the visibility limit is too short !!

BattleZoneAttempt_20241023.gif

Enemis'ships vanish too fast .. they should remain visible longer for us to be able to destroy them.

I don't know yet if there's a solution or what could be this solution.

But for now I'm just very sad, discouraged, disappointed and angry that such an idiot design mistake ruins so many hour of work.
I wanted so much to offer Oric community with a nice BattleZone ..

BattleZone.dsk

Arrow left/right turns camera
Space: shoot

Totally disgusted !!!

[Dbug]

So, what's the reason for the visibility limit being too short?
We know from Chema's 1337 that it's technically possible to have 3D stuff with some reasonably long distance view, maybe there's something reusable there?

Regarding performance, one trick that can make the game faster and look better is to actually embrace the fact that you are supposed to be sitting inside a tank and probably looking through some kind of periscope or small window or digital screen, so you could totally have a frame around the game play section to reduce the amount of stuff you have to refresh.

Like for example the moder versions of Ballezone look like that:

image_2024-10-23_135116927.png

image_2024-10-23_135056800.png

[jbperin]

So, what's the reason for the visibility limit being too short?

Design error number ONE. When a ship or a missile goes out of the radar-covered area, it is removed from the 3D scene.
==> presence of shapes in the 3D scene must depend on their own position rather than on the radar capabilities

Design error number TWO. Positions of camera, ships, and missiles are signed 8 bits values.
==> I should use 16 bits unsigned values .

Idea for the future: Add a mecanism of "variable Level Of Detail". Use vector graphics for far objects and use 3d projection only for close object or even only for static objects of the scene.

We know from Chema's 1337 that it's technically possible to have 3D stuff with some reasonably long distance view, maybe there's something reusable there?

Good idea. I shall look at the code of 1337 again. There's a long time since I last read it.

And in the meanwhile, I humbly invite Chema (or anyone interested) to "peer review" or audit the code of the project. It is herebelow

BattleZone4Oric.zip

Regarding performance, one trick that can make the game faster and look better is to actually embrace the fact that you are supposed to be sitting inside a tank and probably looking through some kind of periscope or small window or digital screen, so you could totally have a frame around the game play section to reduce the amount of stuff you have to refresh.

For now, considering the amount of C in the code, I wasn't too concerned by the performance.
It was still very early stage of the dev, nothing really optimized.
However, the idea of a frame around the viewport should have been thought at the beginning. One more design mistake from me.

I use a screen copy buffer to avoid flickering during rasterisation maybe it is possible to put a "frame" in it before copy to screen.
Or maybe use a smarter copy to screen method that can preserve a frame on screen.

[Chema]

I made similar design mistakes in 1337.

First, the use of the lib3D library from Stephen Judd, imposed a limit to the max distance between vertices in order to gain speed. That was nice, and gave me some extra cycles which I needed for double buffering, but later on I found it too restrictive. Some big ships (IIRC the Anaconda and the Thargoid) had to be scaled down a bit and there was no solution to include stations.

Second, I used 16 bit integers for space coordinates, when I should have used 32 bit to create larger empty space areas. This was not too problematic in the end, but I should have known better.

There was also something with how I calculated visibility which made flat wings need two polygons and the still disappear when parallel to the pov.

About then double buffer, check the routines in 1337 with unrolled loops. And it is always better to dump less area, thus the usage of a frame. That will improve speed a lot (less to clear, less to copy). Even if drawing in a back buffer using all the screen and only clearing/dumping what is visible.

I cannot promise to check your code, I'm afraid. I have too little time (so many things to do, which leaves me little time for Oric ). If you can point me to a specific routine, I could have a look at it, though.

[ibisum]

@jbperin: did you read this article about the original development of Battlezone? Ironically, the original programmer also felt some disgust with the project ..

https://news.ycombinator.com/item?id=42591818

[jbperin]

@jbperin: did you read this article about the original development of Battlezone? Ironically, the original programmer also felt some disgust with the project ..

https://news.ycombinator.com/item?id=42591818

Hey .. very interesting resource !!
Thank you for the link.

It will likely be useful whenever I resume this battlezone project.