It is currently Tue Nov 21, 2017 9:04 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Sun Aug 27, 2017 2:25 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
I proposed the idea of making an engine that acts like the SNES has a large CHR-ROM based sprite system in another thread, to make sprite animation easier for other programmers. I didn't know if people just didn't notice it, or weren't interested, or didn't understand what it is.

So I'm going to ask, if people are not interested in this, what types of stuff do people want to see happen next? If we still want to create a generic game engine for beginners, does anybody want to include some built in special effects, such as HDMA line scrolling effects? In the near future I might be able to do almost real-time sprite scaling and rotation on multiple sprites at once, just as long as I have plenty of SRAM to use. It might be a fun little cheat for beginners who might be unimpressed with static sprites.


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 6:05 pm 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1826
Location: DIGDUG
I read most of the code you write, but I don't understand alot of it.

You mentioned "beginners". If you want to help beginners, you need to explain things very very basic. Like...here's a step by step to go from a GIMP image, to create a CHR file. Here's how to load it to VRAM. Here's how to put it on screen. Here's how to animate it. Lots of details.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 7:26 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
The code I posted this morning I don't think is that bad.

The thing is there's already lots of tutorials on ASM and PPU. A lot of people complain about the lack of example codes. The example codes I post aren't supposed to "teach" ASM, they're just there as a high level abstraction.

Languages like C and C++ use mysterious functions, and nobody cares how those functions work.


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 9:14 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3114
Location: Nacogdoches, Texas
That last comment. :lol:

What I would include in a game engine, is an object table (obviously), a system for adding and deleting objects, a system for actually running object code, a system for creating metasprites (with flipping and no size or shape limitations; just add or subtract x/y values) an animation engine, (it offsets a table with the offsets for metasprite data and tile data; can loop or end) and a dynamic VRAM engine (16x16 and 32x32 sized sprites are fitted into sprite VRAM wherever possible, making sure there are no redundant graphics to save space). Palettes for sprites would be fitted into CGRAM dynamically as well. (My system of changing palettes midscreen is probably overkill, and takes Hblank time...) A CGRAM and a VRAM uploader would need to be made. (The VRAM uploader would probably have separate routines for 8x8 tile/tilemap uploads and sprite tile uploads, as the latter can be more hardcoded.)

I don't really have much of an opinion on what should be included for backgrounds, because I feel like it varies too much from game to game to have an all-purpose solution. Some games need to deal with scrolling freely, while others only need to scroll on one axis at a time, and often only in one direction, and still others don't need to scroll at all. Games that can scroll more linearly can have new tiles uploaded as the screen scrolls, whereas I really don't know how you'd do this with scrolling freely. I think a system that decides when objects are spawned or destroyed should also be up to the programmer to make; some games need to process things offscreen while others don't; some games don't even need to keep track of what has been destroyed if they only scroll forward. I thing both sprite collision and background collision can also be done by the programmer. Fighting games, for example, don't need background collision beyond one "if less/greater than".

Basically, anything that actually touches hardware registers needs to be included. Anything that deals with hardware limitations (128 sprites, 16KB sprite VRAM, 8 sprite palettes) should also be included, although a programmer using the engine should obviously still be cognizant of these limitations even if they don't have to worry about them as much. Things that don't deal with video hardware and are thus no different to program for than on any other system (collision detection, physics, object creation/destruction) don't need to be included.


Top
 Profile  
 
PostPosted: Sun Aug 27, 2017 11:08 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
psycopathicteen wrote:
I proposed the idea of making an engine that acts like the SNES has a large CHR-ROM based sprite system in another thread, to make sprite animation easier for other programmers. I didn't know if people just didn't notice it, or weren't interested, or didn't understand what it is.

I vote for 3., I don't understand what this is.


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 1:40 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 582
Even in the best case, interest in such a SNES game engine will be low. Look at comparable engines targeting other platforms, they barely have one user each.


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 5:16 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19239
Location: NE Indiana, USA (NTSC)
To gain interest from modders, your engine will probably need to be as complete as that of Super Mario World, as will its sample block and sprite graphics.


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 5:44 am 
Offline
User avatar

Joined: Tue Apr 05, 2016 5:25 pm
Posts: 146
My engine already does everything Espozo's first paragraph mentions except for dynamic sprite and CGRAM allocation. I am actually halfway to the former, because I have updated my sprite placement function so that objects can override the tile and attribute bytes of OAM and therefore offset themselves to use the sprite slot they were assigned.

The World system that I'm planning for later will be in an optional module that is invoked by scene specific code so only games that need it will be using it.

Edit: I also don't have metasprite flipping because I'd rather have flipped versions as separate definitions for performance.

_________________
SNES NTSC 2/1/3 1CHIP | serial number UN318588627


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 2:24 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
So I'm referring to the code on this page:
viewtopic.php?f=12&t=10957&start=285

I made a diagram to explain what it does.

Attachment:
VRAM system.png
VRAM system.png [ 45.27 KiB | Viewed 1369 times ]


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 5:36 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3114
Location: Nacogdoches, Texas
HihiDanni wrote:
I also don't have metasprite flipping because I'd rather have flipped versions as separate definitions for performance.

I actually don't either for the same reason. I figured people would be put off by a lack of flipping, but really, if we wanted anyone to adopt a game engine like this, we would have to make a tool for building metasprites anyway, in which case you could implement a feature where a mirrored duplicates can automatically be made. It will take more ROM space, but I and more than likely others could give a shit.

@Psychopathicteen Why would you need SRAM for this? I wonder how much faster this would be than the system I have. (Which still isn't finished...) It doesn't look like it would offer any advantage other than speed, because of how 16x16 and 32x32 sized sprites have to be separated. I guess if there are two different objects with some sprites in common, it would save space over my system that only checks whether an entire object's graphics are in common rather than their individual sprites.


Top
 Profile  
 
PostPosted: Mon Aug 28, 2017 8:05 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
Without using an extremely long table, it would have to compare 128 sprites to 32 slots.


Top
 Profile  
 
PostPosted: Mon Sep 04, 2017 1:54 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
Didn't somebody post a code for writing every sPPU register in vblank a while? That would also be useful for a generic engine.

Found it
viewtopic.php?f=12&t=14457


Top
 Profile  
 
PostPosted: Wed Sep 06, 2017 11:45 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
I decided to make my own shadow sPPU update code, for general use. I discovered a new trick with write-twice registers, where you just need to make a 16-bit write to the high bytes of the register, and it would automatically write the low byte of the next register in one go. The might be an even faster way with PEI, but I'm not sure the exact behavior of writing these registers out of order.

Code:
sPPU_register_write:
php
phd
rep #$30
lda #{shadow_sPPU_regs}
tcd

lda {screen_brightness}
sta $2100

sei
tsx
lda #$210c
tas
pei ({BG1&2_char})
pei ({BG3_tilemap})
pei ({BG1_tilemap})
pei ({BG_mode})

lda #$2132
tas
pei ({color_math_enable})
pei ({window_sub_screen})
pei ({sub_screen})
pei ({window_logic_OBJ})
pei ({window_position_3})
pei ({window_position_1})
pei ({window_settings_OBJ})
pei ({window_settings_1&2})

txs
cli
sep #$10

ldx {window_color_green}
stx $2132
lda {window_color_blue}
sta $2132

ldx {BG1Xlo}
stx $210d
lda {BG1Xhi}
sta $210d
lda {BG1Yhi}
sta $210e
lda {BG2Xhi}
sta $210f
lda {BG2Yhi}
sta $2110
lda {BG3Xhi}
sta $2111
lda {BG3Yhi}
sta $2112
lda {BG4Xhi}
sta $2113
ldx {BG4Yhi}
stx $2114

lda {Mode_7_settings}
sta $211a
lda {parameter_A_hi}
sta $211b
lda {parameter_B_hi}
sta $211c
lda {parameter_C_hi}
sta $211d
lda {parameter_D_hi}
sta $211e
lda {parameter_X_hi}
sta $211f
ldx {parameter_Y_hi}
stx $2120
pld
plp
rts


Top
 Profile  
 
PostPosted: Thu Sep 07, 2017 1:17 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 189
For mode 7 settings for example, why don't use MVN ??


Top
 Profile  
 
PostPosted: Thu Sep 07, 2017 4:17 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2363
They're write twice registers, so I have to do overlapping 16-bit writes.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 20 posts ]  Go to page 1, 2  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