Real-time sprite scaling

Started by ervin, 18:32, 26 June 21

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

sigh

Looking forward to the update.

Trebmint

Hi, I recall that I actually wrote an article on sprite scaling for Amstrad Action back in the day. As I recall it was pretty good. Might be worth looking at.
https://www.cpcwiki.eu/imgs/7/79/Amstrad_Action108_21.jpg


It actually creates its own self modifying code, so its not too slow. If anyone tries it let me know if it works or is any good :)

andycadley

Quote from: Trebmint on 19:55, 05 July 21
Hi, I recall that I actually wrote an article on sprite scaling for Amstrad Action back in the day. As I recall it was pretty good. Might be worth looking at.
https://www.cpcwiki.eu/imgs/7/79/Amstrad_Action108_21.jpg


It actually creates its own self modifying code, so its not too slow. If anyone tries it let me know if it works or is any good :)
I remember reading it back in the day and thinking it was a pretty cool approach, if that counts.  :laugh:

Skunkfish

Quote from: Trebmint on 19:55, 05 July 21Hi, I recall that I actually wrote an article on sprite scaling for Amstrad Action back in the day. As I recall it was pretty good. Might be worth looking at.
https://www.cpcwiki.eu/imgs/7/79/Amstrad_Action108_21.jpg


It actually creates its own self modifying code, so its not too slow. If anyone tries it let me know if it works or is any good

That definitely went over my head at the time!

Did you have a game in mind when you wrote that Rob?
An expanding array of hardware available at www.cpcstore.co.uk (and issue 3 of CPC Fanzine!)

Trebmint

Quote from: Skunkfish on 08:49, 06 July 21
That definitely went over my head at the time!

Did you have a game in mind when you wrote that Rob?
I don't think so. I think I might of been planning to use it for title screen, but its so long ago I can barely remember.

sigh

Out of interest, how difficult would it be to create a 'Wing Commander' type game using this method and your gallery method? They also look like they could work for on rail shooters.

ervin

Hi folks.

I've uploaded scale_2.dsk to the original post.
It runs quite a lot faster than the previous versions, but it's still slow.
There is still much work to be done, but I think there is still a lot more speed to be gained.

ervin

Quote from: sigh on 13:44, 07 July 21
Out of interest, how difficult would it be to create a 'Wing Commander' type game using this method and your gallery method? They also look like they could work for on rail shooters.

My apologies if you are asking this question of Trebmint.

In the case of my program however...
For very large sprites it's hard to say.
For smaller sprites (and certainly a smaller, spectrum-sized screen), it might be quite doable.
I've built into the program the ability to have a sprite sized anywhere from 1 tile up to 8x8 tiles, and any combination in between (e.g. 1x2 tiles, 5x3 tiles etc).

sigh

Quote from: ervin on 16:29, 07 July 21
My apologies if you are asking this question of Trebmint.

In the case of my program however...
For very large sprites it's hard to say.
For smaller sprites (and certainly a smaller, spectrum-sized screen), it might be quite doable.
I've built into the program the ability to have a sprite sized anywhere from 1 tile up to 8x8 tiles, and any combination in between (e.g. 1x2 tiles, 5x3 tiles etc).

Yes - I was thinking about your chunky pixel curator and also what you are attempting now. The reason I was thinking of Wing Commander style is because the actual play area is quite small as most of the game is taken up by the hud. Also, there aren't any real backgrounds as it's just stars, so the only things that really scale are the enemies and bullets as I don't think that the explosions scales.

In many ways, you have already started this with the chunky pixel curator; black background and animated characters?


https://www.youtube.com/watch?v=mfRvCSBD4q0

ervin

#34
Hmmm, I think a simplified version of Wing Commander's presentation may indeed be possible.

However, with the larger pixels in Chunky Pixel Curator, it would be a lot faster, as those pixels are all byte-sized (pardon the pun!).
No byte-splitting or rotating is required for pixels of that size, and I wouldn't need different code paths for masked vs unmasked tiles.
Unmasked tiles are of course faster to draw.

I might do a byte-sized version of my current project once I feel I can't make it any faster.

[EDIT] In either case, for a project like Wing Commander (or anything with sprites that can go off-screen), clipping would need to be taken into account.
And that's much harder with the project I'm working on.

It's certainly possible (in fact I had it working in my BlitzMax prototype), but it would be very difficult, and all the extra code (for every clipping case) would take up a lot of memory.

Writing a generic clipping routine would take up much less RAM of course, but would run a lot slower.
Although it could be done quite efficiently with self-modifying code (which is what I did in Chunky Pixel Curator)... hmmm...

sigh

Would you be able to achieve this on a 64kb machine?

ervin

Quote from: sigh on 01:01, 09 July 21
Would you be able to achieve this on a 64kb machine?


The program is currently running on a 464, but with more graphics the available RAM will run out quite quickly.
Also, as I expand the code to make it faster (by removing asm CALLs and inlining code), the code size is growing rapidly.
So it's hard to say...

ervin

#37
Alrighty, I've uploaded scale_3.dsk to the original post.

I'm afraid I will no longer develop this particular program.
While it is now much, much faster than the original program, it is still nowhere near as fast as what I was hoping to achieve.

The main reason is the byte-splitting/combining required to achieve pixel accurate scaling.
The overhead is just too great.

Instead I will use the ideas from this program in a new project.
I'm interested in seeing how much faster this scaling technique can be without needing to split/combine bytes.

So I'll try a program that draws large "pixels" that are one byte in width, and therefore 4 rasters in height.
It will look very blocky of course, but should run much faster.

sigh

Quote from: ervin on 18:08, 09 July 21


Instead I will use the ideas from this program in a new project.
I'm interested in seeing how much faster this scaling technique can be without needing to split/combine bytes.

So I'll try a program that draws large "pixels" that are one byte in width, and therefore 4 rasters in height.
It will look very blocky of course, but should run much faster.
Your last upload was much faster.
If you are worried about it looking blocky, would you consider to use mode 1 instead? That would also give you extra ram for graphics.

ervin

Quote from: sigh on 12:52, 10 July 21
Your last upload was much faster.
If you are worried about it looking blocky, would you consider to use mode 1 instead? That would also give you extra ram for graphics.

I could use mode 1, except that I want large graphics that take up the same amount of screen real estate, no matter what mode is used.
And that means that the sprites will take up the same amount of RAM, no matter which mode is used.
:(

In any case, I'll see what sort of speed I can achieve with the larger "pixels".
The speed difference should be significant.

I'm considering entering this year's cpcretrodev with a simple game that requires high-speed sprite scaling, and if large pixels make that possible, then that's what I will need to focus on.

ervin

#40
Hi folks.

Well, I haven't been able to leave this alone, and have done a lot of work on it over the last few months.
I have discovered a number of improvements, mainly to do with the scaling algorithm.
Not only is the program a lot faster, but it is a lot smaller as well.

I think it is now fast enough for a game to be feasible!
Not really sure what sort of game... maybe something to do with going down into the ground, or a well, or the ocean?

Anyway, if you're interested, have a look at the attached dsk.
:)

[EDIT] Oops, I forgot to mention... use Z and X to scale the sprite.

zhulien

#41
Have you looked at pitfighter on cpc.  It almost universally trashed as an unplayable bad port.  It does however demonstrate what one sprite scaling method could work like.  In reality that game could have been better, even by turning off the audience it might have gotten better. 

Another possibility is since we now have sdcards and lots of ram, you could prerender lots of things, like wolfenstein 3d did on ms dos.  The prerendering will still benefit from the fastest methods that you can implement.

Then we have some virtual memory algorithms that can work in conjunction with the 64k extra memory and sdcards, (im still waiting for the maxam on emucpc bug to be resolved so I can finish that), but the vm routines really just aid you as a developer to handle megabytes of ram easier.

An example how they could be used.  Imagine you have x sprites all prescaled and stored on sdcard, but you can only fit some of the sprites into physical ram at once. Imagine as you walked from room to room, you accessed a different set of scaled sprites..  logically from a different memory bank, but actually automatically paged in when required. So you are handling a list of a subset of scaled sprites per room.

I know what I said mostly takes the realtime out of realtime sprite scaling, but in the end it is more to do with the result you give the user, not the method.   Unless it is a pure tech demo and it must absolutely be realtime.

ervin

#42
I have looked into paging sprites in as required, even creating a buffer for the most recently used sprite magnifications, and extracting compressed compiled sprites to the buffer in real-time using LZ48 and also with LZX0 (I had written a tool in BlitzMax to create the different magnifications for each 16x16 tile and then convert those to compiled sprite code).

That technique worked very well, and was comparable in speed to what I'm doing now, but of course RAM was the issue.
With my current technique I only have 2 copies of each tile, one positioned on the left pixel of the starting byte, and one positioned on the right pixel (i.e. pre-shifted).
So RAM is no longer a problem.

The 464 has always been my target with this project, as I'd really like to enter another game to cpcretrodev (hopefully a completed game this time!).
I'm reasonably confident that it should be possible.  8)

[EDIT] Tile preparation is now a bit smaller and faster, so there is now less overhead for each tile.

roudoudou

Quote from: sigh on 13:44, 07 July 21Out of interest, how difficult would it be to create a 'Wing Commander' type game using this method and your gallery method? They also look like they could work for on rail shooters.
there is no point using this method for a wing commander like game, you need only to store sprites at different sizes
use RASM, the best assembler ever made :p

I will survive

TotO

Quote from: roudoudou on 08:51, 07 March 22there is no point using this method for a wing commander like game, you need only to store sprites at different sizes
And the result will be better (visual and speed)
"You make one mistake in your life and the internet will never let you live it down" (Keith Goodyer)

ervin

Hi folks.

I've added 3d-based positioning to the program, so that the sprite recedes into the distance correctly when moving away from it.
If you interested in having a look, please try attached file.

At the bottom of the screen is some diagnostic information.

S represents the speed of movement, which ranges from 1 to 32.
This can be changed using the left and right arrow keys.

D represents the distance from the sprite, which ranges from 0 to 1031.
This can be changed using the up and down arrow keys.

Enjoy!

ervin

#46
Hi folks.

I've continued to work on this, with optimisation being a major focus.
I have now pushed the speed as far as my current skill level allows - I have no other ideas on how to make it faster.
Having said that, I'm very very happy with how it runs.

Please forgive the graphics - they are just placeholders and are completely awful!
I've also added concentric rectangles to give a better impression of movement.


I'm now very confident that this technique can be used in a game.
:D

[EDIT] I just realised that I recorded my mouse pointer in the video!
:laugh:

Sykobee (Briggsy)

Looking good, maybe a game flying through hoops (Pilotwings CPC!) is possible.
Or a graphically superior Star Wars trench game.

ervin

I'm thinking of a downward into-the-well style of game.
Something like Bounder in 3D.

Prodatron

Wow, that looks really fast, Ervin!
Each number is a bunch of 16 colour square shaped sprites?
It seems to be close to 50Hz.

GRAPHICAL Z80 MULTITASKING OPERATING SYSTEM

Powered by SMFPacks Menu Editor Mod