Inverted Y origin

The place for codemasters or beginners to talk about programming any language for the Spectrum.
Post Reply
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Inverted Y origin

Post by Hikaru »

Recently, I found it to be convenient to have the Y origin point at the bottom of images (sprites), so that essentially they are drawn starting from the bottom up. This has at least the following advantages:

1) Easy non-intrusive clipping at the top; in your 'next line' procedure, check if your screen MSB is below #40/#C0 (or similar) and exit if so. Normally I'm perfectly happy with drawing beautiful art all over the universe ROM, but in this case I need to be careful not to break stuff at #BFFF and below.

2) Assuming object coordinates are the same as sprite coordinates, and the fact that the latter would then roughly correspond to where objects are 'standing' in a side-view game, the 'do we have floor in there' checks can be done in a more direct fashion, without involving sprite heights and whatnot.

The upside-down drawing isn't a problem in itself as I'm using 128K shadow screen paging. Other than that, I can't seem to think of any potential disadvantages to it; am I missing anything there?
Inactive account
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Inverted Y origin

Post by Ast A. Moore »

I do that with any sprites that I need to clip at the top of the screen. My reasoning has always been the simplified coordinate handling. (E.g. the missile in Yankee is drawn in this fashion.) I never bother checking the ROM boundary when drawing the next line, because in that particular case it’s wasteful; but then I don’t use a screen buffer/shadow screen.

I don’t see any obvious disadvantages, other than taking care of sprite clipping at the bottom of the screen. That, however, can easily be taken care of by creating special lookup values. (Fortunately, we have quite a bit of leeway here, what with the vertical coordinates being only 192 lines out of 256.) Horizontal clipping is a different beast altogether and does require some ugly black magic.

Oh, collision detection must be reworked to take the resulting offset into account. YMMV.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
ZXDunny
Manic Miner
Posts: 498
Joined: Tue Nov 14, 2017 3:45 pm

Re: Inverted Y origin

Post by ZXDunny »

In tight situations where you have a lot to draw, drawing top-down means you can more efficiently race the raster. Drawing from the bottom up means you must ensure that you've got enough time to draw the whole sprite before the beam catches up. Other than that, there's no real issues that I can think of.
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Inverted Y origin

Post by Hikaru »

Cheers. Sounds like it's worth giving it a go then.

I forgot about a small issue with it nevertheless, which is that you'll have to store your sprites upside-down in case you're using the stack to read the data, since POP can only move the data pointer forwards. But this probably just amounts to another 'rule' during the graphics conversion stages, so not really an issue.

I couldn't think of scenarios requiring bottom clipping in an engine like this (basically Mint 128), apart from Ghosts'n'Goblins type undead enemies perhaps, as well as what Joffa does in Hysteria, both of which look somewhat special-case to me. I think kindly asking not to set the Y coordinate above 127 would suffice for a start. :) Or maybe putting a hard limit on it, Zynaps style.
Inactive account
User avatar
Ast A. Moore
Rick Dangerous
Posts: 2640
Joined: Mon Nov 13, 2017 3:16 pm

Re: Inverted Y origin

Post by Ast A. Moore »

Hikaru wrote: Thu Jan 04, 2018 10:44 am you'll have to store your sprites upside-down in case you're using the stack to read the data
Sure. Goes without saying. I remember it was a nightmare to rearranged the graphics as I changed the routines (especially, when switching to arranging data in a zig-zag fashion). Found an online tool that could rearrange comma-separated entries in various ways and the did a lot of copy-pasting between the editor and the browser. Ugh.
Every man should plant a tree, build a house, and write a ZX Spectrum game.

Author of A Yankee in Iraq, a 50 fps shoot-’em-up—the first game to utilize the floating bus on the +2A/+3,
and zasm Z80 Assembler syntax highlighter.
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Inverted Y origin

Post by RMartins »

I'm not really sure if you gain anything from it.

At least in my own sprite code, I always load the the amount of vertical lines the sprite includes.
Clipping vertically is extremely easy, you just have to change were you start in the sprite data, if you clip on top, and/or change sprite total line count if clipping on bottom.
Both these operations are done outside of the main loop, so no speed issue there.

What do you expect to gain in speed from processing in reverse ?
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Inverted Y origin

Post by Hikaru »

RMartins wrote: Thu Jan 04, 2018 10:16 pm I'm not really sure if you gain anything from it.

At least in my own sprite code, I always load the the amount of vertical lines the sprite includes.
Clipping vertically is extremely easy, you just have to change were you start in the sprite data, if you clip on top, and/or change sprite total line count if clipping on bottom.
Both these operations are done outside of the main loop, so no speed issue there.

What do you expect to gain in speed from processing in reverse ?
The short answer is that these forms of clipping don't integrate well with my Sprite System.

1. Drawing a Sprite of a height that isn't a multiple of 8 is not straightforward and requires introducing a 'hack' with several explicit checks into every Sprite procedure for this sole purpose.

2. The 'bytes per line' value is not known in advance. Moreover with unrolled sprites, it is possible for what is logically designated as a single Sprite to be actually stored and drawn as multiple images of different widths and formats depending on the X-shift 0~7. The result here is that, again, it's not possible to keep the clipping code conveniently in one place.

It's possible to identify the common part that can be done before everything else in the sprite-list parser, but the rest of it would inevitably have to be customized for, and replicated across, every individual Sprite routine. I have determined that this was overcomplicated and unnecessary.
Inactive account
User avatar
RMartins
Manic Miner
Posts: 776
Joined: Thu Nov 16, 2017 3:26 pm

Re: Inverted Y origin

Post by RMartins »

Can't you just detect the Clipping possibility, and use a different/specific function to blit it, even if it's more generic/slower then you regular fast Sprite blit ?

A Trick I usually do in some of my blitting routines, is to allow for multiple locations of code entry, so that some registers could be initialised by some other code, and then jump right into the inner loop of the general case.

NOTE: Obviously this is not possible for specially (multi line) unrolled functions, but can still be used on functions that only unroll a single sprite line.

But you could jump into your specialized unrolled function, if you can make the original preamble code, that renders the special clipped part, and then jumps into the inner loop to finish it off (if you can only clip on top).
Hikaru
Microbot
Posts: 100
Joined: Mon Nov 13, 2017 1:42 pm
Location: Russia
Contact:

Re: Inverted Y origin

Post by Hikaru »

I'm sure there's more than one way to skin a cat, mind you. I might revisit that part sometime, but in the end I can only afford that much attention to marginally useful functionality, so it's not a priority at the moment.
Inactive account
AndyC
Dynamite Dan
Posts: 1388
Joined: Mon Nov 13, 2017 5:12 am

Re: Inverted Y origin

Post by AndyC »

It can be a useful technique. From what I recall of digging around inside Dizzy, the Oliver Twin's Panda Sprites worked like that (but without upside down drawing) which proves it can't be an entirely bad idea.
Post Reply