nesdev.org

Khaz wrote:I wonder... Has anybody ever programmed a game that deliberately detects and avoids slowdown? Like put a scanline interrupt right near the bottom of the picture where, if processing isn't complete by then, it cuts short everything remaining somehow to keep a constant framerate, at the expense of some objects not getting updated regularly?

Khaz wrote:I mean I can see engineering it to never go over the limit by design, or to alternate processing between frames

Khaz wrote:I'm having trouble deciding how to spawn enemies in my own game. I'm still working with the 64x64 rooms (with size-16 tiles) plan which I kinda like as a model for pretty much the whole game. I'd thought I'd be able to get away with just spawning everything on entry, but it really only takes a handful of objects in existence before things start to lag.

One thought I've had is to spawn everything on entry, but keep things deactivated until you get close enough. My system can handle 64 objects, which shouuuuld be enough to cover a whole room? Though that includes projectiles and platforms and pickups and everything, so then again maybe not. (P.S. I hate sprite platforms so much.)

Khaz wrote:I wonder... Has anybody ever programmed a game that deliberately detects and avoids slowdown?

I'm not sure how to handle when things go off screen, whether to disable them or despawn them completely, or just ignore collisions... One way or the other, constantly comparing everything to the screen/player position to see if it should be active or not sounds like a lot of extra processing on its own.

UnDisbeliever wrote:Castle Platformer loaded all enemies (maximum of 64) into RAM on level start.
There was a active scrolling window twice the size as the screen in which entities will be processed.

If an enemy moves outside it it is moved into the deactivated list. If a projectile moves outside it then it is removed from play.

I'm going to experiment a bit with the next engine. I think having three scrolling windows; one to deactivate the entities (the largest, 2x screen), one to activate the enemies (1.5x screen), one to load graphics (the smallest, 32px larger then screen) will minimise or outright eliminate this bug.

Khaz wrote: I'm having trouble deciding how to spawn enemies in my own game. I'm still working with the 64x64 rooms (with size-16 tiles) plan which I kinda like as a model for pretty much the whole game. I'd thought I'd be able to get away with just spawning everything on entry, but it really only takes a handful of objects in existence before things start to lag.

psycopathicteen wrote:Can we see some examples of code that gets repeated a lot per frame?

psycopathicteen wrote:Might as well show it.

;============================================================================
; ENEMY PROJECTILE SUBTYPE - 06
;----------------------------------------------------------------------------
	lda.w objSubList6First		;start checking with first object in subtype list
	sta.w registerT

_procNMYProjCollPlyr:
	lda.w registerT
	cmp.w #$FFFF				;If object index is FFFF, we're at the end of the list
	bne _notDoneNMYProjCollPlyr
	jmp _doneNMYProjListCollPlyr

_notDoneNMYProjCollPlyr:
	tax
	
	lda.w $0000+obj0NextTypeObj, x		;fetch next object OF SAME SUBTYPE
	sta.w registerT				;store this in case current object gets terminated during collision

	lda.b obj0XPosn	              ;test position
	sec
	sbc.w $0000+obj0XPosn, x
	cmp #$0010
	bpl _procNMYProjCollPlyr
	cmp #$FFF0
	bmi _procNMYProjCollPlyr

	lda.b obj0YPosn
	sec
	sbc.w $0000+obj0YPosn, x
	cmp #$0010
	bpl _procNMYProjCollPlyr
	cmp #$FFF0
	bmi _procNMYProjCollPlyr

;=========================
	;it's a hit, do stuff

[...]

doneNMYProjListCollPlyr:

tepples wrote:If all projectiles can collide with all actors, then perhaps it might be wise to sort all projectiles by X position so that the collision testing can do a binary search for projectiles near each actor.

You don't need "register T". You could just keep it in X-index. Other than that, your code looks really efficient.

It could be something else like BG-layer collision, or animation-related stuff. Are you still using a DKC-style dynamic animation engine?

Kasumi wrote:Here's my favorite collision routine for object/object hits: http://atariage.com/forums/topic/71120- ... try1054049

You may have to do some preprocessing for SIZE1+SIZE2-1 if the objects aren't a fixed size, but even with that it's quite fast. Should work in 16bit.

psycopathicteen wrote:Your idea of 64x64 tile rooms sounds like a good idea. You can have 6 bits of subpixel accuracy, and 10 bits of pixel coordinates in a single word. If you want to stretch the room to an entire level, you can have the level map scroll itself and still have a big enough spawning window.