Space Force [raxiss]

Want to discuss about Demos on the Oric, here you are !
User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Space Force [raxiss]

Post by rax »

HI :),

This is also a game I started two years ago.
I wanted to try making a vertical shooter after being inspired by Twilighte's SWIV.

One of my main goals was to experiment with 12x12 tiles and their different coloring.
I had several concepts at various levels, but I never decided whether the action should take place on the planet or in space.
I wasn't able to come up with a complete plot for the game and had decided to leave it for a while and... it's been 2 years :)

I'm sharing what I've done so far:





Attachments
spcfrc.dsk
(131.5 KiB) Downloaded 14 times
User avatar
Dbug
Site Admin
Posts: 4144
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Space Force [raxiss]

Post by Dbug »

Very nice, indeed reminds me of the Swiv tech demo :)
User avatar
ibisum
Wing Commander
Posts: 1544
Joined: Fri Apr 03, 2009 8:56 am
Location: Vienna, Austria
Contact:

Re: Space Force [raxiss]

Post by ibisum »

This is very intriguing - do you see paths for optimization? As I recall, Twilighte got into some very twisty territory with SWIV in terms of optimizing draw lists .. not to compare, but I wonder if you've still got room for smoothness .. ?
User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Re: Space Force [raxiss]

Post by rax »

Dbug wrote: Fri Nov 11, 2022 7:49 pm Very nice, indeed reminds me of the Swiv tech demo :)
Thanks @Dbug.
ibisum wrote: Sat Nov 12, 2022 12:15 am This is very intriguing - do you see paths for optimization? As I recall, Twilighte got into some very twisty territory with SWIV in terms of optimizing draw lists .. not to compare, but I wonder if you've still got room for smoothness .. ?
I think some things can be optimized, but I don't think there will be much improvement in speed.

The big problem (in my opinion) is that I'm also using a double buffer (bg buffer and tmp buffer), which means that what we see on the screen is drawn three times. The process below is as follows:
1. bg buffer is moved down and new tiles are drawn.
2. copy the bg buffer to the tmp buffer.
3. draw the sprites into the tmp buffer.
4. copy the tmp buffer to the screen.

Each of the buffers are 3k and are moved with unrolled procedures (which take up a lot of space)

As an example, I will give that only a simple copy of a full screen from the memory in the hires area (0xa000) will notice the slow drawing.
User avatar
Dbug
Site Admin
Posts: 4144
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Space Force [raxiss]

Post by Dbug »

rax wrote: Wed Nov 16, 2022 4:21 pm The big problem (in my opinion) is that I'm also using a double buffer (bg buffer and tmp buffer), which means that what we see on the screen is drawn three times. The process below is as follows:
1. bg buffer is moved down and new tiles are drawn.
2. copy the bg buffer to the tmp buffer.
It's probably possible to optimize that by not scrolling the background buffer at all and instead have a smart copy function that copy source data using some modulo offset.

So on the first frame:

Code: Select all

lda 0
sta 
lda 1
sta 
lda 2
sta
(...)
lda 199
sta 
and on the second frame you only update one line of graphics and patch the copy code:

Code: Select all

lda 199
sta
lda 1
sta
lda 2
sta
(...)
lda 0
sta 
That basically removes one complete copy
User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Re: Space Force [raxiss]

Post by rax »

This is the idea to try :).
I'm not sure if it will work, but as I recall it was a similar way to tile the screen on NES console.
User avatar
peacer
Flight Lieutenant
Posts: 441
Joined: Wed Jun 09, 2010 9:23 pm
Location: Turkey
Contact:

Re: Space Force [raxiss]

Post by peacer »

What a beauty again..

With such talent and capacity why don't you try to program much easier looking "river-raid" like game for the Oric?

Once in the past I tried to make such attempt as "oric-raid" . Of course it was soo primitive. Only text-byte scrolling , no crash or scoring etc but just an humble demo..

User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Re: Space Force [raxiss]

Post by rax »

peacer wrote: Sat Nov 19, 2022 12:22 am ... why don't you try to program much easier looking "river-raid" like game for the Oric?
Nice demo :)

I was thinking about a "river raid" a while ago. I have never been able to figure out how the game's levels are generated, and there are many different levels at that (https://www.vgmaps.com/Atlas/Atari2600/ ... id-Map.png).
In order for us to create this game and for you to be able to scroll full screen, this must be in text mode. There, the main problem, in my opinion, is that the size of one character is 8 pixels and when scrolling you can see a rather irritating flicker.

p.s. I've also thought about "Pitfall 2600" :)
User avatar
peacer
Flight Lieutenant
Posts: 441
Joined: Wed Jun 09, 2010 9:23 pm
Location: Turkey
Contact:

Re: Space Force [raxiss]

Post by peacer »

I can't think of any algorhytm for the leves.. Probably draawn each one by one.. I've seen the maps previously but I never thougt there were that much levels.. Well oric raid does not have to be hundreds of levels too :)

But again surely it has to be diffucult to scroll.. Your space force gave me think if its doable too :)

Ah pitfall.. yes my another dream on Oric :)
User avatar
Chema
Game master
Posts: 2923
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN
Contact:

Re: Space Force [raxiss]

Post by Chema »

Scrolling is a pain on the Oric. Twilighte's swiv demo is a masterpiece and it is probably the slowest scroll at which a game would be playable... or enjoyable.

If you want to go fullscreen (almost) then it's probably a no-no.

I used text mode in Oricium, which gave me 50 fps of scroll for only the big ship, but went down to 25fps when displaying enemies. But there are quite a few drawbacks, apart from the bumpy scroll (though it is less noticeable if it is horizontal, as it is 6 pixels at at time, not 8, and the pixel-based star scrolling helped visually).

- The Oric has too few redefinable characters. I had to alternate LORES0 and LORES1 to be able to have a decent tileset. Each enemy took 4x2 chars to render (2 sets of 4 to avoid glitches). All that is quite a pain to deal with.
- Lateral movement might work, but vertical movement is difficult to control, as it is one character at a time.
- Bye-bye color.

I have toyed (for some time now) with the idea of using text mode and sub-character scrolling. Dbug even made a demo. It was based on redefining characters, but then you have to design the game so it could adapt to the technique, and you'll have even less tiles (you'll need special tiles for combinations in the borders and such). Definitely, not easy to achieve, but possible.

I also considered the idea of having two bands scrolling up and down at pixel level and in Hires mode with colors, and the rest of the play area in text mode with some kind of sub-char scrolling with some simple background and small details, concentrating on the player and enemy graphics, lots of bullets and so on... Never had time to explore that, plus having hires back again at the bottom would probably destroy things...

I many times wondered how they achieved those nice scrolls on the spectrum (have a look at Cobra, for instance). I guess the z80 could do many more tricks to help in this area.
Last edited by Chema on Tue Nov 22, 2022 5:56 pm, edited 1 time in total.
User avatar
Dbug
Site Admin
Posts: 4144
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Space Force [raxiss]

Post by Dbug »

As usual on the Oric the core of the issue has to do with the amount of data to move in one frame, and the fact there is no double buffering.

Technically we don't need all these intermediate buffers, but we also want to avoid flickering as much as possible, which is why we tend to use buffers, to do composition where it's invisible, and then "blitt" that to the screen.

In practice, there are methods that can be used to reduce copying, but they end up being extremely complex to apply, and tend to use quite a lot of memory.

The fastest possible way to display an image on the Oric is basically to have the image stored as code as immediate values, so something like that:

Code: Select all

LDA #first_byte_of_the_image
STA $A000+0
LDA #second_byte_of_the_image
STA $A000+1
(...)
LDA #last_byte_of_the_image
STA $A000+7999
This takes 2 bytes per LDA, 3 bytes per STA, so that's 8000*5 bytes = 40000 bytes, and takes 2 cycles per immediate LDA, 4 cycles per absolute long STA, so that's 8000*6 cycles = 48000 cycles, knowing that we have about 20000 cycles per frame when running at 50fps, so just doing that already takes 2.4 frames :cry:

Obviously that's not a viable option.

The opposite option is the naive double for loop with two pointers in zero page, the amount of memory used is trivial, but the time literally explodes because of the number of loops and index management.

So in general we try to get something in between, with some code unrolling in one direction (either horizontal and vertical), and looping on the other direction, which is slower than the first example, but manageable in term of memory usage.

A common solution to reduce the processing time is to have some UI elements, like some high-scores, title logo, etc... because if you don't have to update 20% of the screen, it means the code now runs 20% faster.

The big difficult in games really are sprites, because they move, you need to be able to restore the background where they previously were present, but if you do that on the HIRES screen, if the electron beam passes over the area where you just erased the sprite before drawing the new one, you will see a flickering mess on the screen.

If your drawing code is fast enough that it can do that in less than a frame, then you are good to go, but when doing HIRES animation WITH a scrolling, there's no way to do that faster than 50hz, which is why we use intermediate buffers.

That being said, there are methods that can be used to scroll on place the areas where there are no sprites, and use some optimized erase/draw for the sprites using some "dirty rectangle" methods, but it's extremely complicated to implement.
User avatar
iss
Wing Commander
Posts: 1480
Joined: Sat Apr 03, 2010 5:43 pm
Location: Bulgaria
Contact:

Re: Space Force [raxiss]

Post by iss »

@Dbug: Compact and straight to the point - best explanation I've ever read ! 8)
User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Re: Space Force [raxiss]

Post by rax »

I completely agree with everything @Dbug and @Chema say
Chema wrote: Tue Nov 22, 2022 3:25 pm I used text mode in Oricium, which gave me 50 fps of scroll for only the big ship, but went down to 25fps when displaying enemies. But there are quite a few drawbacks, apart from the bumpy scroll (though it is less noticeable if it is horizontal, as it is 6 pixels at at time, not 8, and the pixel-based star scrolling helped visually).
I'm also of the opinion that scrolling horizontally, which is only 6 acids, should be less irritating to the eyes. tried this on SPACE COWBOY https://forum.defence-force.org/viewtopic.php?t=2268
I didn't like the result because of the flickering


Chema wrote: Tue Nov 22, 2022 3:25 pm I have toyed (for some time now) with the idea of using text mode and sub-character scrolling. Dbug even made a demo. It was based on redefining characters, but then you have to design the game so it could adapt to the technique, and you'll have even less tiles (you'll need special tiles for combinations in the borders and such). Definitely, not easy to achieve, but possible.
What is this demo?


Chema wrote: Tue Nov 22, 2022 3:25 pm I also considered the idea of having two bands scrolling up and down at pixel level and in Hires mode with colors, and the rest of the play area in text mode with some kind of sub-char scrolling with some simple background and small details, concentrating on the player and enemy graphics, lots of bullets and so on... Never had time to explore that, plus having hires back again at the bottom would probably destroy things...
That would be interesting to see. I still can't imagine it.

Chema wrote: Tue Nov 22, 2022 3:25 pm I many times wondered how they achieved those nice scrolls on the spectrum (have a look at Cobra, for instance). I guess the z80 could do many more tricks to help in this area.
I have also wondered why that is. I guess the z80 does better because of its higher frequency and instruction set.
I fail to understand how the APPLE II (which has the same 6502 @ 1.023 MHz processor) has better scrolling in its graphics mode than the ORIC, when scrolling is much more complicated due to inconsistent graphics addresses (I think zxspectrum graphics addresses are inconsistent)
User avatar
rax
Flying Officer
Posts: 152
Joined: Tue Jul 24, 2018 3:16 pm

Re: Space Force [raxiss]

Post by rax »

Dbug wrote: Tue Nov 22, 2022 4:01 pm ...
Extremely detailed and best explanation! :)

Basically all this buffering (as we know) is done just to avoid jitter. Without it sometimes the flickering is quite annoying and would make you quit the game.

Most 8-bit machines of the time had either sprite support or a higher frame rate which contributed to a better user experience.

The principle you described seems interesting to try (I've been thinking about something similar).
I think I can program this in ORICART . We have 512k available there and a code can be made to run directly from the ROM.
User avatar
Dbug
Site Admin
Posts: 4144
Joined: Fri Jan 06, 2006 10:00 pm
Location: Oslo, Norway
Contact:

Re: Space Force [raxiss]

Post by Dbug »

I believe that was this demo:
MARIO.tap
(7.56 KiB) Downloaded 14 times
It's all in C with memcopy for everything, so it's super slow, but the idea was to see if it would work to move "large objects" at the block level, and some background details at the pixel level by doing real-time reconfiguration of the charset
Post Reply