Log In  

Now that I'm remembering code I wrote on other computer platforms (ow my head !) I am reminded of one unique feature that the Commodore Amiga 1000 had, and that was HARDWARE SPRITES.

Yessirree, I did not remember until now, just how powerful these little things were.

You had 16 of them, they used color sets 17-19, 21-23, 25-27, and 29-31. They could be any size vertical but only 16-pixels across. Not very exciting in itself, but let me explain.

In the Commodore Amiga, you could use one of these hardware sprites and it would appear on top of graphics. No, that's not correct. They would appear on TOP of graphics. That is, you did not plot them, you INVOKED these sprites, and when you did, when you changed their position, for instance, the background of what was beneath them was always remembered and untouched.

In the Commodore Amiga, you could give a hardware sprite an acceleration, that is, you could give one say AX+=.1 and AY=0 and it would creep to the right across the screen, but ALSO continue to creep even after you stopped running your code.

Curious little things. With the many ignored suggestions, I'd like to add this one, that PICO have the ability of being able to work with 16 "hardware" sprites. However, instead of being limited to 8 or 16-pixels across, you can choose the number of tiles it works with.

It also would not have a limited palette but be able to use the full 15-color set (with zero to show background through).

The advantage of this would be clear. You could invoke these sprites and not have to worry about "cleanup" behind when they moved off of an area. By giving them an acceleration, they would continue to move and not need code to continuously "push" it.

Additionally, you could not READ these sprites. That is, if you had a solid black screen and you invoked a sprite, say 8x8 that was white to appear in the top-left-hand corner, reading directly the pixels there would STILL be black, as these "hardware" sprites have their own invisible layer and would not be read by PGET().

MHWSPR(n,x,y,h,v) Make HW Sprite ID #n from tile set position x,y size across h and v down
RHWSPR(n) remove HW Sprite ID # n
HWSPR(n,x,y,a,b) move sprite #n to pixel x,y or, if zeroes, a & b are acceleration with real numbers.
s=(HWSPRCOL(n)) return 0 if no collisions or ID # if collided into other HW sprite

Collision checking is done by overlapping pixels, not area.

P#31491 2016-10-22 19:25 ( Edited 2016-10-29 01:04)

I actually really love this idea. i've never thought of that type of possibility before. it seems like the only way this could happen is if there were truly two drawing layers to work with? i can't think of how i'd do that in SDL but i dont know much about it in the first place. if SDL can't do it i'm not sure Pico8 ever could

P#31718 2016-10-25 02:11 ( Edited 2016-10-25 06:11)

Glad you like the idea ! :)

I guess what's need to say here is, =I= can write this. And I know if I can, I'm sure ZEP can too.

Even the Atari 2600 had hardware sprites:

https://en.wikipedia.org/wiki/Atari_2600_hardware

What is SDL, GC ?

P#31729 2016-10-25 10:47 ( Edited 2016-10-25 16:39)

https://www.libsdl.org/

SDL is the graphics/game library that pico8 is built with. i've used it before in other languages, but here in pico8 we are getting a curated game engine built with that underlying graphics library.

i guess hardware sprites would be more like some emulated chunk of memory that would have its own draw routines somehow. i'm just a novice so i have no idea if you could emulate that functionality for pico8.

are you thinking you could write it in Pico8 itself? have you seen how the emulators of those machines with hardware sprites do it?

P#31785 2016-10-25 22:53 ( Edited 2016-10-26 02:53)

The code could be written. My time here is almost done. I'll return for the next update of PICO. At that time, I promise I'll write you the code to do this.

[1] Can select any Sprite of any size from tiles
[2] Comes with optional auto-black outline when plotted
[3] Can read the pixels behind it
[4] Does not overwrite pixels beneath it
[5] Can move it's location and background stays the same

P#31979 2016-10-28 21:04 ( Edited 2016-10-29 01:04)

[Please log in to post a comment]

Follow Lexaloffle:          
Generated 2024-03-28 21:51:47 | 0.007s | Q:16