Sonic and Sega Retro Message Board: HCKTROX - Viewing Profile - Sonic and Sega Retro Message Board

Approaching current situation, I wanna just throw something here...


It was an original idea by other of mine friends, but I was asked to join and help on anything it required, maybe documenting stuff about original engine, helping with the code logic, stuff like that. Main game coding is ran under SuperFX chip for this version

Mistergambit, on 24 August 2014 - 08:23 AM, said:

flamewing, on 24 August 2014 - 09:22 AM, said:

Hmmm... Not exactly:

- At some point, like flamewing said, some objects could indeed had the ability to be rendered with the background coordinates.
- However, what I tried to say, is the following:

From ObjPos_Load (If we're in GHZ1):

		; . . .
		lea	(ObjPos_Index).l,a0 ; load object list pointers
		movea.l	a0,a1
		adda.w	(a0,d0.w),a0	; load object list for the level
		move.l	a0,($FFFFF770).w ; load first pointer, ObjPos_GHZ1
		move.l	a0,($FFFFF774).w ; load first pointer, ObjPos_GHZ1
		adda.w	2(a1,d0.w),a1
		move.l	a1,($FFFFF778).w ; load second pointer, ObjPos_Null
		move.l	a1,($FFFFF77C).w ; load second pointer, ObjPos_Null
		; . . .

and like so:

		dc.w	ObjPos_GHZ1-ObjPos_Index, ObjPos_Null-ObjPos_Index

Such dead code/pointers lead me to think that at some point S1 had the ability to load two obj lists at same time, perhaps each with different coordinates, the second possibly meant for objects rendered by setting the background coordinates at obRender.

My english isn't this good to explain it very well, but if you understand, it's required to work like this in the case you need to have background sprites at "free positions"
I re-setup it for the trees that appear between FG and BG planes here:

HCKTROX, on 10 February 2014 - 09:40 AM, said:

I'm answering here to avoid keeping off-topic in the other post...

Although this isn't completely DPLC-related, would it be possible to do some simple VRAM emulation, allowing multiple files to be loaded? Not only would help to decide whether or not to use DPLC under certain circumstances (you know, DPLC's main cons are the lag it takes to draw or their ROM space),but it would come really handful in situations like this:

Excuse me for bumping this up, but I have just noticed a little issue trying to build it for my SegaCD hack:

	subi.w	#System_Stack,d3			; d3 = -1 * number of bytes to print

This line gave me a little error, which I fixed this way...

	subi.w	#(System_Stack)&$FFFF,d3		; d3 = -1 * number of bytes to print

I know this may look insignificant, but you know, perhaps not everybody knows about it or whatever :v

* NOTE: I'm using the 1.42 (beta, build 92) version (Win32).

Didn't these complaints already happened since the huge change Windows 3.1 had against Windows 95? Many people complained about the new design (although the complaints weren't overcrowded because internet wasn't that big and accessable as today).
I guess it's just a matter of time to get used to a new style, just like we done before.