Uzebox revolution!

Use this forum to share and discuss Uzebox games and demos.
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Uzebox revolution!

Post by paul »

I realize you'll probably iron out the creases later, but just to save anyone some trouble, if you can alter SetTileTable to also update screenSections[0].tileTableAdress when SCREEN_SECTIONS_COUNT is not defined by the user, then backwards compatibility can be restored for mode 3 games that previously didn't have to consider screen sections. It's not a problem for development because if you're not using screen sections, then you'd just use the older kernel.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox revolution!

Post by uze6666 »

I realize you'll probably iron out the creases later, but just to save anyone some trouble, if you can alter SetTileTable to also update screenSections[0].tileTableAdress when SCREEN_SECTIONS_COUNT is not defined by the user, then backwards compatibility can be restored for mode 3 games that previously didn't have to consider screen sections. It's not a problem for development because if you're not using screen sections, then you'd just use the older kernel.
Hmmm...I surely could. However I was wondering about making the "new" mode 3 with scrolling a brand new mode. First to avoid adding code for backward compatibility (with 64k we got to cut everything useless) and also because it's not the same resolution. Due to unssuficient cycles, the horizontal resolution is lowered a 29x28 instead of 30x28. Speaking of which, would you guys find preferable an "even" resolution like 28x28 instead?

-uze
User avatar
paul
Posts: 457
Joined: Sat May 02, 2009 8:41 am
Location: Brisbane, Australia

Re: Uzebox revolution!

Post by paul »

would you guys find preferable an "even" resolution like 28x28 instead?
I want to say yes, but I'm not sure why.
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Uzebox revolution!

Post by Jhysaun »

I feel like I should say yes, but I don't know why either.

If we eliminate that column, will there be more cycles to add even more functionality? Like flipping?

Also I think you've said before that scaling sprites is not possible, but wouldn't it be a simple matter of sending out 2 pixels when there should only be one?

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox revolution!

Post by uze6666 »

If we eliminate that column, will there be more cycles to add even more functionality? Like flipping?
No more cycles per-se, they are currently eaten by the rasterizer to process fine scrolling. But sprite flipping is a pre-render operation done during V-blank so this is still on track. Sprites scaling is possible, also during Vblank. Thing is, it's of very little value in this case (IMHO) because we have very limited RAM/ramtiles and a single scaled sprite could eat all ramtiles. Plus it would somewhat take more CPU too. With the atmega1284 that would become an interesting feature...

-uze
keithkml
Posts: 30
Joined: Tue Feb 03, 2009 10:56 pm
Location: Baltimore, MD

Re: Uzebox revolution!

Post by keithkml »

Hi Uze, I can't get my code working with the kernel-4-uzeamp even though it works fine with the plain rev-beta4 kernel. I get crashes in the emu as pasted below.

I don't have a working TV yet so the emu is all I've got :) How do you debug on the actual uzebox hardware?

Also - I'm trying to be able to modify ramtiles at runtime as we discussed in another thread, but in combination with the mode3 sprite engine. Basically to partition the ramtiles into 2 parts: application-controlled ramtiles, and uzebox-sprite-engine-controlled ramtiles. My naive approach was just to change ProcessSprites to initialize free_tile_index to RESERVED_RAM_TILES, which the application is free to define. However this doesn't seem to work, though it does produce something beautiful:

[youtube]http://www.youtube.com/watch?v=3LjIM9eP294[/youtube]

So... any ideas on how to get app-managed ramtiles working in conjunction with the sprite engine?

Anyway - the errors & crash from the new mode3+scrolling kernel:

Code: Select all

illegal write of 0 to addr 1100, pc = 22f2
illegal write of 0 to addr 1101, pc = 22f2
illegal write of 0 to addr 1102, pc = 22f2
...
illegal write of 0 to addr 1178, pc = 22f2
illegal write of 0 to addr 1179, pc = 22f2
new input routines detected, switching emulation method.
illegal write of 45 to addr 115b, pc = 3112
illegal write of 84 to addr 115a, pc = 3114
illegal write of 6f to addr 1160, pc = 3117
illegal write of 1 to addr 1100, pc = 311f
...
illegal write of 18 to addr 1147, pc = 3125
illegal write of 10 to addr 1160, pc = 3178
illegal read from addr 8400, pc = 3989
illegal read from addr 8401, pc = 3989
illegal read from addr 8402, pc = 3989
illegal read from addr 8403, pc = 3989
illegal read from addr 8404, pc = 3989
illegal write of 1 to addr 1176, pc = 39a3
illegal write of 0 to addr 1101, pc = 312d
illegal write of 0 to addr 1117, pc = 312f
illegal write of 0 to addr 112d, pc = 3131
illegal write of 0 to addr 1143, pc = 3133
illegal write of 3e to addr 1164, pc = 3136
illegal write of 6b to addr 1163, pc = 3138
illegal write of 3e to addr 1167, pc = 313e
illegal write of 6b to addr 1166, pc = 3140
illegal write of 0 to addr 1162, pc = 3142
illegal write of 0 to addr 1161, pc = 3144
illegal write of 0 to addr 1159, pc = 3146
illegal write of 0 to addr 1158, pc = 3148
illegal write of 0 to addr 115c, pc = 314a
illegal write of 0 to addr 115f, pc = 314f
illegal write of 0 to addr 115e, pc = 3151
illegal write of 1 to addr 116d, pc = 355a
illegal write of 1 to addr 1169, pc = 355c
illegal write of 5 to addr 1168, pc = 355e
illegal write of 0 to addr 116c, pc = 3560
illegal write of 1 to addr 116b, pc = 3562
illegal read from addr 116a, pc = 23a3
illegal read from progmem addr f800 (ignored)
illegal read from progmem addr f810 (ignored)
illegal read from progmem addr f820 (ignored)
illegal read from progmem addr f830 (ignored)
illegal read from progmem addr f800 (ignored)
illegal read from progmem addr f810 (ignored)
illegal read from progmem addr f820 (ignored)
illegal read from progmem addr f830 (ignored)
...
illegal read from addr 2700, pc = 29ad
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox revolution!

Post by uze6666 »

Checkout the free RAM. When i checked you code against the /kernel-4-uzeamp RAM usage was >100%. That will crash the system. Memory usage is bigger in this branch mainly because the VRAM is 32x32 tile instead of 30x28 to handle scrolling.
Also - I'm trying to be able to modify ramtiles at runtime as we discussed in another thread, but in combination with the mode3 sprite engine. Basically to partition the ramtiles into 2 parts: application-controlled ramtiles, and uzebox-sprite-engine-controlled ramtiles. My naive approach was just to change ProcessSprites to initialize free_tile_index to RESERVED_RAM_TILES, which the application is free to define. However this doesn't seem to work, though it does produce something beautiful:
This one is more tricky, I'll need to be home to check this out.

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

Re: Uzebox revolution!

Post by uze6666 »

Some progress on mode3. Well, should I say lack of it thereof. As it turns out, sprites flipping is getting much more complex than I though. My brain is aching with multiple problems at once trying to come up with a working & performing algorithm. The problem is to make it fast as possible since with the atmega1284 extended memory, more sprites will also mean much more CPU (and by then I don't want to dwelve in that again!). Additionally to sprite flipping, someone asked about sprite flickering like mode2. My two first attempts failed miserably and I need to go back to the drawing board. :|

-uze
User avatar
Jhysaun
Posts: 214
Joined: Tue Nov 04, 2008 12:32 am

Re: Uzebox revolution!

Post by Jhysaun »

uze6666 wrote:Additionally to sprite flipping, someone asked about sprite flickering like mode2. My two first attempts failed miserably and I need to go back to the drawing board. :|

-uze
Do the sprite flipping in C :D

>J
Lerc wrote:I intend to use my powerful skills of procrastination to ensure that when I get to making things, the chips will be available.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Uzebox revolution!

Post by uze6666 »

Do the sprite flipping in C :D
Tried that already and even then, it's damn complex. :? I have no real choice then laying it down in C and then try to convert it to assembler.

-uze
Post Reply