Single pixel motion in high res?

[Spinnetti]

Clearly there's lots I don't understand properly. Buddy Don plugged in a high res routine (not sure which one) in our base game code, and viola! we are creating our next game in high res. No major complications, Don set up the base screen and I made the sprites with little routines to paint our sprites and animate frames. Only hang up is the the high res motion is only vertical - I can move up and down one pixel at at time (192) but horizontally, it still moves in 8bit chunks (32) col instead of 1bit steps (256). Is this just how they all work, or is there a driver or easy to plug in routine that allows single pixel addressing in both directions without having to shift bits across byte boundaries or use pre-shifted graphics etc?

Thanks!

[mrtinb]

My guess is that pre shifted graphics (spites in 8 versions), is the easiest and fastest solution.

[Fruitcake]

Only hang up is the the high res motion is only vertical - I can move up and down one pixel at at time (192) but horizontally, it still moves in 8bit chunks (32) col instead of 1bit steps (256). Is this just how they all work

The hi-res routine Don is using is pseudo hi-res, similar to that used in Software Farm's Forty Niner. Unfortunately the technique suffers from the limitation you've described and is a consequence of how the ZX81 hardware works.

For horizontal movement finer than 8 pixels at a time, you will need to create sprites for each horizontal position you require. Getting nice looking results can be tricky due to less than half of the 256 possible pixel patterns being available. This is why most pseudo hi-res games move their sprites at the character cell level rather than the pixel level. Software Farm's Forty Niner and Rocket Man are a bit of an exception in that they move their sprites 4 pixels at a time, which explains why the player's sprite looks a bit distorted as he walks.

For full pixel control you would need to change to the WRX hi-res system, but this requires a compatible RAM pack that has been suitably modified to support the technique. Most users probably have this facility now (it is built into the ZXpand and Chroma interfaces, plus mainly existing RAM packs can easily be modified), so it all depends on whether you want your game to run on stock ZX hardware or to take advantage of newer / modified hardware.

[Spinnetti]

Thanks for the feedback. Looks like we are using the WRX routine. We now have zxpand, TS1500s with internal 16k and emulators, so aren't trying to stay within the limits of a stock machine. Maybe I'm just doing it wrong. If I point to the hi rez display file, and increment one position in x, its 8 bits. So even with WRX, you can't address at the pixel level in x?

I get conceptually how to do the pre-shifted sprites across two bytes (assuming 8 bit sprites), but other than creating all the pre-shifts, not clear how to actually implement that or do collision detection in practice.

[Fruitcake]

So even with WRX, you can't address at the pixel level in x?

Correct. A byte represents a block of 8 horizontal pixels. So if you want to move things horizontally at the pixel level then you either need to define pre-shifted sprites, or shift them in a buffer as and when needed before copying them into the display file.

I get conceptually how to do the pre-shifted sprites across two bytes (assuming 8 bit sprites), but other than creating all the pre-shifts, not clear how to actually implement that or do collision detection in practice.

Ah, that is a more fundamental issue. As mentioned, Rocket Man uses pre-shifted sprites for the player moving 2 pixels at a time (not 4 pixels as I incorrectly stated earlier). So you could refer to how that game operates (disassembly of it is available here). But as you are using WRX then you might find referring to online disassemblies of Spectrum games more useful as they will likely be shifting sprites at the pixel level and doing so as and when required. There might be disassemblies of ZX81 WRX games available that also do this which others may be able to point you at (I don't know of any myself).

[mrtinb]

The complexity arises, when you want to do other than custom characters in 8 x 8. So most WRX just simulate UDG with WRX, because that’s easier. I know that’s not what you want, but it’s the most common.

I don’t know if the source for BerZXerk is available, but I think that does 1 pixel scroll. Against the Elements might have 1 pixel scroll as well: http://www.fruitcake.plus.com/Sinclair/ ... ements.htm

[Fruitcake]

The complexity arises, when you want to do other than custom characters in 8 x 8. So most WRX just simulate UDG with WRX, because that’s easier.

That's a good point. A few games will be doing horizontal pixel scrolling, e.g. the conversion of Space Invaders, almost certainly does and I think the source might be available for it.

I don’t know if the source for BerZXerk is available, but I think that does 1 pixel scroll.

BerZXerk is pseudo hi-res and so won't be scrolling at the pixel level.

Against the Elements might have 1 pixel scroll as well: http://www.fruitcake.plus.com/Sinclair/ ... ements.htm

Against the Elements is also pseudo hi-res and doesn't scroll horizontally at the pixel level either.

[dr beep]

You can use a shifted udg in memory and place that on screen. You do a shift left or right on the udg.
When you move 8 pixels you need to shift back a full byte. By heart I think my hires games BLOCKY uses this method.

[Spinnetti]

Thanks for the feedback, suggestions and links. Don was thinking if we are doing HRG, byte moves are pretty ugly still and we should move by pixel.

Is there any real difference between WRX and UDG? I started this whole journey some time back just looking for easy UDG replacing the existing chr set with my custom ones, and I'd only replace some of them - maybe just the inverted ones. That would be my ultimate desire actually - is there an easy way to just map the character set elsewhere then modify the codes I want? All my code stuff would then still work as-is, I'd just have prettier graphics.

I guess we can build a "sprite engine" that takes x,y in the 256x192 space (for x moves, probably divide x by 32, then the remainder is the index for the amount of bits to rotate, with the leftover rotated the other way in the next byte maybe?) and prints out a graphic but that will be a fair project sounds like.

[mrtinb]

The easiest way to do UDG-like graphics without UDG hardware, is to use dr beep's USCII (viewtopic.php?f=6&t=3124). Here you have 25 custom char in addition the the ROM charset. It can be programmed in Basic and machine code.