Silly little sprite/scroll demo

Use this forum to share and discuss Uzebox games and demos.
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Silly little sprite/scroll demo

Post by havok1919 »

uze6666 wrote:[Yeah, and for myself, I really don't like the sound of the noise channel, since the mixing frequency is too low. So it's pretty hard to make effects sound good, specially for music (like hi-hats, snares, etc) :( . So with samples, the real issue is space...unless we accept fixed samples (no pitch control). I could then implement a simple ADPCM decoder and we could easily get 3:1 to 4:1 compression. Enough to store very interesting samples I think.
Heck yeah... I was just thinking LPCM at a multiple of the hsync rate or something for 'easy', but ADPCM could be nice-- not a lot of cycles as I recall. I always thought 3 bit ADPCM sounded a little too "gravel-ly". 4 bit was good. Of course 4bit ADPCM only gives 2:1 ove 8 bit LPCM which would be no CPU impact to speak of... Just pick something that Goldwave or other common/cheap/free editors can grok. (Dialogic had an ADPCM, OKI had their own, etc.)

Any idea how many bits of resolution you're really getting out of the PWM output? I also suspect a lot of low-cost filters will start to roll off at ~10KHz to try to keep Hsync noise out of the audio channel. (...and a steeper filter is rather a lot of parts-- I have that one on the baseboards, but I admit I haven't tried populating it. Keep adding parts to my Digikey order!)

-Clay
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

Now if we can just get some of that resolution back... The pixels are quite obviously rectangular.
And what about 208x220? Based on Lerc's idea, I wrote a new inner loop at 7 clocks per pixels (instead of 10). If we also encode the sprites data the same way and pre-compute visible sprite line adresses in a new way I though, I think I can double the sprites per line...while at the same time lowering RAM usage...isn't that great or what! ;)

So I think that with the 644 that's pretty much the best I can do for full screen scrolling with sprites. To make that happen I had to use 8 pixels wide tiles, so that gives a 26x25 tiles screen. That will still yield slightly rectangular pixel but worst, IHMO, non-square tiles (that's why I used 6x8 tiles originally). However what about say 8x9 or 8x10 tiles instead? They should look pretty square with that resolution.

Also, I confirmed that using the "CodeTiles" approach, it will also be possible to have a 5 cycles/pixel implementation for tiles-only mode (even looks good for 4 cycles/pixel too). That gives above NES/SNES resolution with near square pixels on 8x8 tiles. So that will be quite nice for certain types of games, like Megatris. Note that these modes could probably support full screen scrolling too. So that would also be great for Boulder Dash types of games.

Told you there was still lots of juice left in these little beast! :lol:

Cheers,

Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Silly little sprite/scroll demo

Post by havok1919 »

uze6666 wrote:And what about 208x220? Based on Lerc's idea, I wrote a new inner loop at 7 clocks per pixels (instead of 10). If we also encode the sprites data the same way and pre-compute visible sprite line adresses in a new way I though, I think I can double the sprites per line...while at the same time lowering RAM usage...isn't that great or what! ;)
Holy crap! Everyone repeat after me... Uze! Uze! Uze! ;-)
So I think that with the 644 that's pretty much the best I can do for full screen scrolling with sprites. To make that happen I had to use 8 pixels wide tiles, so that gives a 26x25 tiles screen. That will still yield slightly rectangular pixel but worst, IHMO, non-square tiles (that's why I used 6x8 tiles originally). However what about say 8x9 or 8x10 tiles instead? They should look pretty square with that resolution.
Personally, I like the 8 wide tiles because it makes for those nice binary shifts to calculate pixel position to tile background. Divides are still kinda spendy in clock cycles on the AVR. For me, I'd probably still prefer 8 pixel tall tiles-- again, it just makes some screen position based stuff easier to calculate and seems a bit more "natural". I might just be old and crotchety about that. :-P
Also, I confirmed that using the "CodeTiles" approach, it will also be possible to have a 5 cycles/pixel implementation for tiles-only mode (even looks good for 4 cycles/pixel too). That gives above NES/SNES resolution with near square pixels on 8x8 tiles. So that will be quite nice for certain types of games, like Megatris. Note that these modes could probably support full screen scrolling too. So that would also be great for Boulder Dash types of games.
Damn, man-- you're really firing on all cylinders now! :-) I'm excited. This is really sweet sounding-- the only downside... Now I'm holding off on a "real game" until I get that 26x25(208x220) w/ sprites. ;-)
Told you there was still lots of juice left in these little beast! :lol:
You weren't kidding. VERY respectable performance!

-Clay

...and PS... I hate you now because all my carefully hand-drawn 6x8 tile graphics have to be redone. :lol:

Image
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

Last post for today, it's damn late here!
I'd probably still prefer 8 pixel tall tiles-- again, it just makes some screen position based stuff easier to calculate and seems a bit more "natural". I might just be old and crotchety about that. :-P
Yeah, I think so ;) . Seriously, I'll see how it look. Performance issues is much less of a concern on the Y axis... But,indeed, I agree that 8x8 is the ideal shape (perhaps, I'm also getting too old :D ).
..and PS... I hate you now because all my carefully hand-drawn 6x8 tile graphics have to be redone. :lol:
Image
Hey! Wait a second, those buildings just reminds me of Rampage, one of my favorite games of all times! Is it pure hazard? Hehe, anyways, very cool looking! :D

I've got no official time frame for releasing the new version but the sooner the better since it's fresh to my memory now. Although I didn't actually implement the algorithm, I've did put it on 'paper' cycle-by-cycle. So I may hit a wall in the end, but my "god feeling" always told me it was feasible :lol:.


Cheers,

Uze
havok1919
Posts: 474
Joined: Thu Aug 28, 2008 9:44 pm
Location: Vancouver, WA
Contact:

Re: Silly little sprite/scroll demo

Post by havok1919 »

uze6666 wrote:Last post for today, it's damn late here!
Hahah... I'm doing my usual "vampire hours" here.
Yeah, I think so ;) . Seriously, I'll see how it look. Performance issues is much less of a concern on the Y axis... But,indeed, I agree that 8x8 is the ideal shape (perhaps, I'm also getting too old :D ).
Might not be a big deal one way or another. One thing about smaller tiles-- I tend to do a lot of graphics/positioning based on minimizing the required tiles to save memory-- seems like larger tiles a lot of the time just end up with just a few pixels in a corner of some image, yet you burn a whole tile for it. *shrug* Not a problem until you're low on memory. ;-)
Hey! Wait a second, those buildings just reminds me of Rampage, one of my favorite games of all times! Is it pure hazard? Hehe, anyways, very cool looking! :D
Good eye! Yeah, I was using Rampage for inspiration. A few years ago we did a little home-arcade game for a company down here and they had an *ahem* "not excellent" TV they put inside the cabinet. It was missing so many vertical lines of resolution I had to redraw all the graphics from the arcade game to make the tiles smaller so we could fit it on the screen. :roll: I remembered doing that before, so I just started playing around with a similar look and feel, albeit in LOTS more colors!
I've got no official time frame for releasing the new version but the sooner the better since it's fresh to my memory now. Although I didn't actually implement the algorithm, I've did put it on 'paper' cycle-by-cycle. So I may hit a wall in the end, but my "god feeling" always told me it was feasible :lol:.
Sounds good... Whenever there's a beta I'll pounce on it and try it out.

-Clay
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

One thing about smaller tiles-- I tend to do a lot of graphics/positioning based on minimizing the required tiles to save memory-- seems like larger tiles a lot of the time just end up with just a few pixels in a corner of some image, yet you burn a whole tile for it. *shrug* Not a problem until you're low on memory. ;-)
One nice side effect of going to 8 pixel wide at that resolution was that it gave 26x25 tiles. Hence it fits in a 32x32 video ram map with enough room for scrolling (I need a binary number to do line wrapping). Otherwise I would have needed 64x32, basically wasting a lot of RAM for nothing.

About tile height, I will see if it can be a compile time option. Should make everybody happy then. ;)

Uze
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

Any idea how many bits of resolution you're really getting out of the PWM output?
Well, though to see on my scope, but should have 256 levels no? Perhaps we loose the lsbit but no more to my ears.

Uze
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

Holy crap! Everyone repeat after me... Uze! Uze! Uze! ;-)
Well, don't repeat it too loud...Yesterday I went waaay over my head and actually hit the wall :( . It was perhaps way too late, I forgot to process 2 pixels out of 8 in the loop! :oops: So I don't see how I could do what I said. It looks more I will be able to do like 8 (or even worst 9) cycles/pixels. However, the bit about more sprites per line still looks good.

I'll keep you posted. Next time I make a announcement, I will be backed by running code!

Uze
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Silly little sprite/scroll demo

Post by uze6666 »

I just tried 8 cycles/pixel and it will still not fit. Damn. Why is that? LDIs doen't help?

Code: Select all

;ROM BG tile 10 cycles (20 bytes * 8 = 160 bytes)   
   ldi r21,0x00		;pix 5
   ldi r20,0xff      ;pix 4      
   out PORTA,r16 
   ldi r19,0x33      ;pix 3
   ldi r18,0x56      ;pix 2   
   ldi r17,0x67		;pix 1
   ldi r16,0x2c		;pix 0
   movw ZL,r24		;load return adress
   ijmp         ;back to rom tile loop 

I looked at it closely and using LDI's seems a good deal at first but considering you need 2 cycles to "call' the tile, 1 to set the return address and 2 more to return, we're left with a small gain of only 6 cycles for a 6x8 background tile (6 LPMs=18 cycles), so over a whole loop, not enough it seems (for me :? ). Considering all the extra flash it gobbles and overall complexity, I'm not sure I will spend more time on this for the time being. I'll leave that to others to find out. I will still look to improve sprites per lines, because this has more potential.

So Clay, you may stick with your 6x8 tiles for the foreseeable future! ;) Looking for that rampage game...

Uze
Lerc
Posts: 64
Joined: Sat Aug 30, 2008 11:13 pm

Re: Silly little sprite/scroll demo

Post by Lerc »

I envisaged using an rjmp at the end, chances are you can be close enough. (little springboard loops interleaved with tiles if you have too many tiles) gives you a clock back from reloading Z.

btw, while I throw around ideas.

For tiles only mode, you could do quite a nice paletted mode with colors in registers 0..15 (or however many can be spared)

Code: Select all

   out PORTA, r0
   mov r17,r5
   mov r18,r9
   out  PORTA,r0
   mov r19,r10
   mov r20,r9
   out PORTA,r9
   rjmp overthere



overthere:
  out PORTA,r17
  LD ZL,X+
  out PORTA,r18
  LD ZH,x+
  out PORTA,r19
  add ZH, r??  (row count-  assuming that tiles are interleaved so that tilen(0,1) is 256 bytes(maybe words given we're talking program memory here) after tilen(0,0) )
  clock cycle going spare here
  out PORTA,r20
  ijmp

; note loop ends by having a magic tile containing exit code

also note that I've never actually written any avr code before so I may be making all kinds of broken assumptions.

also also note this method uses 7 pixel wide tiles, and only really the first three pixels need to conform to the palette, you could ldi the other pixels (and if you are really cunning you can change the palette with special tiles mid-scanline)
Post Reply