It is currently Tue Dec 18, 2018 12:52 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 17, 18, 19, 20, 21, 22, 23 ... 30  Next
Author Message
PostPosted: Fri Aug 25, 2017 12:11 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
Haunted: Halloween '85 for NES does something similar with its sprite CHR. It emulates a sprite system with 256 16x16 CHRs, uploading two per frame to one of two buffers allocated to each entity and switching to the next animation frame only once all needed 16x16s are in place. On Super NES, it should be easier, as you don't need two buffers if no single cel needs more than 5K.

But you still need someone to draw plausible sprite cels with which to test a sprite system including this sort of OBJ-ExGrafix simulator, so that you don't end up over-relying on peculiarities of your synthetic test tiles.


Top
 Profile  
 
PostPosted: Fri Aug 25, 2017 12:44 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
Or you can just make the code not peculiar.


Top
 Profile  
 
PostPosted: Fri Aug 25, 2017 1:15 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
You might not know your architecture is peculiar until you plug in real data and discover that it's not as flexible or efficient as you thought it'd be. It doesn't have to be final data, just representative data.


Top
 Profile  
 
PostPosted: Fri Aug 25, 2017 2:18 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
Well, I guess I would have to come up with a separate version for 8x8 & 16x16 sprites, and 16x16 & 32x32 sprites.

EDIT:
I'm guessing that using 16384 16x16 would be limiting to games larger than 16-megabits. So you can fix that problem with extra SRAM, because you need a table to store the VRAM location of every sprite.

If you want to use a lot of SRAM, then lorom is better.


Top
 Profile  
 
PostPosted: Sat Aug 26, 2017 8:33 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
Okay, I just wrote an example code for a simple "convert arcade-style sprite attributes to SNES-style sprite attributes" system. I wonder where Espozo is, he might be interested in this.

Code:
// "CHR" is the name for the table of 14-bit (or 15-bit) ROM CHR numbers for 128 sprites.
// The routine converts the 14/15-bit CHR values to the SNES's native 9-bit CHR values.
// "CHR_allocation" is a table of where each 14/15-bit CHR is mapped to what VRAM slot.
// Each slot has a hardcoded 9-bit CHR value
// "slot_CHR" says what 14/15-bit CHR value each slot cooresponds to.
// "active_slot" flags if the slot is being used or not.  If $ffff, then the slot needs to be DMA'd.
// "sprite size" table declares if a sprite is 16x16 or 32x32

manage_VRAM:
ldx #$007e
-;            //clear active slot list
stz {active_slot},x
dex #2
bmi -

ldy #$00fe
-;            //check all active slots
ldx {CHR},y
lda {CHR_allocation},x
and #$00ff
tax
inc {active_slot},x
dey #2
bmi -

ldy #$00fe
-;            //this loop allocates missing sprites and converts CHR values
ldx {CHR},y
lda {CHR_allocation},x
and #$00ff
bne +
jsr allocate_CHR      //allocate missing sprites
+;
tax
lda VRAM_slots,x
sta {CHR},y         //replace 14-bit (or 15-bit?) ROM CHR value with
dey #2            //SNES's native 9-bit CHR value
bmi -
rts

allocate_CHR:
phy
lda {sprite_size},y
bne allocate_large_sprite
ldy #$0040         //small sprites are allocated in slots 32-63
-;
lda {active_slot},y
beq +            //open slots have "active_slot" as #0
iny #2
cpy #$0080
bne -
ldy #$0000         //VRAM full error gets NULL slot number
bra +

allocate_large_sprite:
ldy #$0010         //large sprites are allocated in slots 8-31
-;
lda {active_slot},y
beq +            //open slots have "active_slot" as #0
iny #2
cpy #$0040
bne -
ldy #$0000         //VRAM full error gets NULL slot number

+;
lda #$ffff
sta {active_slot},y      //#$ffff marks slots to DMA
tya
ora {CHR_allocation},x
sta {CHR_allocation},x      //table entry is expected to have a low byte of #0
txa
ldx {slot_CHR},y
sta {slot_CHR},y
sep #$20
stz {CHR_allocation},x
rep #$20
tya
ply
rts

VRAM_slots:
dw $ffff,$ffff,$ffff,$ffff,$ffff,$ffff,$ffff,$ffff   //NULL slots (only 0 is used)
dw $0000,$0004,$0008,$000c,$0040,$0044,$0048,$004c   //32x32 slots
dw $0080,$0084,$0088,$008c,$00c0,$00c4,$00c8,$00cc
dw $0100,$0104,$0108,$010c,$0140,$0144,$0148,$014c
dw $0180,$0182,$0184,$0186,$0188,$018a,$018c,$018e   //16x16 slots
dw $01a0,$01a2,$01a4,$01a6,$01a8,$01aa,$01ac,$01ae
dw $01c0,$01c2,$01c4,$01c6,$01c8,$01ca,$01cc,$01ce
dw $01e0,$01e2,$01e4,$01e6,$01e8,$01ea,$01ec,$01ee


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 8:16 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3409
Location: Richmond, Virginia
Don't worry, I'm still alive. :lol: Could you give a summary of what this code does? I read the description at the top, and glanced at the code, but I don't understand what is going on. It sounds like you want to somehow increase the CHR size of OAM to 15 bits instead of 9, but this is a hardcoded limitation. The end of your comment says something about 16x16 and 32x32 sized slots; is this related to the system we're doing of dynamically looking for space in VRAM for sprite graphics?


Top
 Profile  
 
PostPosted: Mon Nov 13, 2017 12:20 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
I thought more about this idea, and I thought that it might be easier to do 16x16 sprites in groups of 2, for a lot of reasons:

-half of the SNES's memory space can be used for sprites.
-32x32 and 16x16 sprites would have the same alignment.
-All sprite pairs have a page aligned address.
-DMA routine can be made more efficient. Possibly around 5kB at once without bars.

The downsides are slightly less flexible 16x16 sprites, and doing 48x48 rotating sprites would have a much more confusing mapping.


Top
 Profile  
 
PostPosted: Tue Jan 23, 2018 11:52 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
In this post, GradualGames pointed out that the asset complexity even on the NES is greater than that on the Atari 2600, and backers of an RPG Maker-style tool that targets NES are clamoring for a counterpart to the Unity engine's Asset Store. This would be even greater for the Super NES.


Top
 Profile  
 
PostPosted: Tue Jan 23, 2018 2:29 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
If they can make an NES game maker program, maybe they can make an SNES game maker too, even if doesn't take 100% of the system's resource.


Top
 Profile  
 
PostPosted: Wed Jan 24, 2018 2:11 am 
Online

Joined: Tue Oct 06, 2015 10:16 am
Posts: 857
Anything can happen if there's enough funding :lol:


Top
 Profile  
 
PostPosted: Wed Feb 21, 2018 4:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20898
Location: NE Indiana, USA (NTSC)
MiniMacro (who goes by Quack Man in FamiTracker community Discord) recommended more samples:
groboclown.net's XM instrument archive


Top
 Profile  
 
PostPosted: Fri Feb 23, 2018 1:33 am 
Offline

Joined: Sun Nov 23, 2014 12:16 pm
Posts: 276
I talked to John (gamester81) and told him to release or sell his Justice Beaver SNES creation tools when they are done with that project. He said that he would have to talk with the SNES programmer to see if he was interested in doing it.

If people are willing to sell their own SNES homebrew tools or do kickstarters to improve or develop SNES tools it would really help the SNES homebrew community and scene.


Top
 Profile  
 
PostPosted: Mon Feb 26, 2018 7:34 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2779
I'll be looking forward to that.


Top
 Profile  
 
PostPosted: Mon Mar 05, 2018 3:38 pm 
Offline

Joined: Wed Nov 30, 2016 9:59 pm
Posts: 57
tepples wrote:
In this post, GradualGames pointed out that the asset complexity even on the NES is greater than that on the Atari 2600, and backers of an RPG Maker-style tool that targets NES are clamoring for a counterpart to the Unity engine's Asset Store. This would be even greater for the Super NES.


Oh gawd, the Unity Asset store. How to make a game not survive a game-engine-you-didn't-write update.

We really do need some kind of "Simple"/"Retro" assembly-code game engine that can run on a NES/SNES/MD by outputting the necessary 6502/65c816/68K assembly game code/assets, that works on Higan or a real SNES/Super NT. If it can validate on the real hardware, then having a IL output (for LLVM) would let it be compiled with other machine-native engines that have the capability to display graphics and play midi/tracker style music.

At any rate, the amount of games that I see being made in Unity or GameMaker that are 2D pixel sprite games, but lack the color range, or even input responsiveness of an actual retro game kinda makes me disappointed over and over again. This isn't a call to stop making 2D sprite games in Unity, but rather these games simply don't have the retro aesthetic other than being "pixelated"

_________________
I come from the net. Through systems, peoples and cities to this place.


Top
 Profile  
 
PostPosted: Mon Mar 05, 2018 4:54 pm 
Offline

Joined: Mon Dec 11, 2017 4:01 pm
Posts: 28
Erockbrox wrote:
I talked to John (gamester81) and told him to release or sell his Justice Beaver SNES creation tools when they are done with that project. He said that he would have to talk with the SNES programmer to see if he was interested in doing it.

If people are willing to sell their own SNES homebrew tools or do kickstarters to improve or develop SNES tools it would really help the SNES homebrew community and scene.


That's very interesting!

Do you know what is the base of their toolset? (ASM or C?).
Did they also create some time saving tools (level editor, sprite animation manager, etc.), like the ones HihiDanni has planned for SuperFeather?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 17, 18, 19, 20, 21, 22, 23 ... 30  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group