Jump to content
IGNORED

Flying Shark


Asmusr

Recommended Posts

I'm playing around with the graphics from Flying Shark for the ZX Spectrum. First iteration is a brute force monochrome scroller, but we can do better, right? ☺

 

Sorry for the dummy question: I've plugged the dsk file in the JS99'er emulator

What should I do to load the game?

Have you started from the ZX sources ? Are they online ?

Link to comment
Share on other sites

 

Sorry for the dummy question: I've plugged the dsk file in the JS99'er emulator

What should I do to load the game?

Have you started from the ZX sources ? Are they online ?

 

It's probably easier to load the cartridge image shark8.bin. No I haven't started from the source code but from a map.

  • Like 1
Link to comment
Share on other sites

Nice looking tile maps! What graphics mode will this use?

 

This is bitmap mode. Not so much because the individual tiles have a lot of color, but because when you scroll vertically color splashes can be avoided in bitmap mode. More precisely the mode will be a hybrid mode with one color table covering the whole screen and 3 pattern tables. If scrolling if too slow in this mode I will have to use 1 pattern table only, but then I will only be able to use 8 sprites.

  • Like 4
Link to comment
Share on other sites

As the level fits in half screen and you only use one color bank, you could try some sort of double buffering.

 

Basically, for middle and lower bank you can use the spare room in vram under the color table using up to 256 alternate tiles, while the upper bank needs to be filled on fly, but if you manage to show only 128+1 tiles in the upper bank you could really have a full double buffering system by swapping colors and patterns from 0000h to 2000h and back.

 

In the upper bank you could use tiles 0-127 with patterns in 0000h and colors in 2000h and tiles 128-255 with colors in 0000h and patterns in 2000h

 

Thinking a bit more,having colors shared, middle and lower banks should use tiles 0-127 and tiles 128-255 accordingly to what you use in the upper bank.

This makes the idea less attractive, as you cannot freely use all the tiles not involved in the level rendering

Edited by artrag
Link to comment
Share on other sites

As the level fits in half screen and you only use one color bank, you could try some sort of double buffering.

 

Basically, for middle and lower bank you can use the spare room in vram under the color table using up to 256 alternate tiles, while the upper bank needs to be filled on fly, but if you manage to show only 128+1 tiles in the upper bank you could really have a full double buffering system by swapping colors and patterns from 0000h to 2000h and back.

 

In the upper bank you could use tiles 0-127 with patterns in 0000h and colors in 2000h and tiles 128-255 with colors in 0000h and patterns in 2000h

 

Thinking a bit more,having colors shared, middle and lower banks should use tiles 0-127 and tiles 128-255 accordingly to what you use in the upper bank.

This makes the idea less attractive, as you cannot freely use all the tiles not involved in the level rendering

 

My idea is to upload the tiles on the fly, but only the tiles I need based on a sliding window. My analysis shows that there will be max 106 tiles active at any point, and that could probably be reduced a bit by reducing the base tile set (there are many tiles that look very similar). Because there are fewer than 128 tiles I can use alternating name tables (one with 0-127 and another with 128-255) for double buffering, but I still need to see how fast this will be.

  • Like 1
Link to comment
Share on other sites

Before I try to improve things I wanted to show how a brute force scrolling with colors look.

 

I have two linear-circular screen buffers in CPU RAM, one for patterns and one for colors, that I update with a single pixel line every frame, and then I push the whole thing to the VDP.

 

As expected there's a lot of screen tearing (due to lack of double buffering) and it pretty slow (pushing almost 7K to the VDP every frame).

 

shark8.bin

  • Like 9
Link to comment
Share on other sites

Here is the first version of the double buffered scrolling backgrounds. If you leave it running it will take you through all 4 levels.

 

The speed is slightly faster when there are fewer unique tiles on the screen. If it wasn't for the sprite duplication bug in the 9918A it could run twice as fast in half-bitmap mode, but if this turns into a game I will need more than 8 sprites on the screen.

 

For some reason it's not working in MAME? I have tried it on my F18A console where it's working fine, but I haven't tried it on a 9918A console.

flying-shark-8.bin

flying-shark.rpk

Edited by Asmusr
  • Like 5
Link to comment
Share on other sites

Yes, Warzone II is great, I converted it to ROM format, but that's for another thread. The difference is that Warzone II is running in graphics I mode, so colors are more limited. And Warzone II is also working with a very limited set of graphics. The new thing in my algorithm (compared to Titanium etc) is that I only update the visible tiles and bring in more as needed, so greater variation in the graphics is possible. To see how it works, look at the VDP chars (F9) in Classic 99 while the demo is running.

  • Like 5
Link to comment
Share on other sites

There is no question that this is the far more visually and technically advanced game. The issue unfortunately will come down to speed of play. Are you considering perhaps using the GPU or will this be just a demo?

 

No I'm not planning to make this dependent on the F18A. If I did the scrolling could have be done much simpler and faster, and the graphics could have been more colorful, even without the GPU. But I might make a F18A version that will run faster simply because the F18A doesn't have the sprite duplication bug in half bitmap mode, so I only have to update 1 pattern table instead of 3.

  • Like 2
Link to comment
Share on other sites

You can have sprite update and game logic executed two or three times per scroll step. In this way the game speed would be perfectly tunable leaving the background scrolling slowly.

 

Yes that's my plan. I will probably run the sprite update and game logic in an 30Hz "interrupt routine" and spend all remaining time scrolling.

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...