37 replies to this topic

[MarkeyJester]

Oh I get what the window plane is....



The lava is on the high plane, the platform is a sprite, but its overlapping the lava thats in high plane, therefore its in the foreground (like the metalstuff in slz).
But the window plane is the items displayed while in debug mode, like the ring. The window plane acttually takes whatever is on the high plane, and puts it on the stuff that are on the foreground. Nice I finally understand!

Wrong, that is not the Window plane, that's an FG plane tile set high plane via the most significant bit.

PCCF MLLL LLLL LLLL

L = Tile ID
M = Mirror flag
F = Flip flag
CC = Palette line
P = plane

And the debug items are sprites.

The Window plane is different, it masks the low AND high plane tiles in the FG, and is not used in Sonic 1. A good example of it used would be Sonic Crackers, when the game is paused, that Yellow bar appears, THAT is the window plane, it remains in place, while the FG is free to move, but it masks the FG where ever a tile in the Window plane is set.

[Hanoch]

Wait a minute, there are sprites, and they have high priority and low priority. The FG graphics are in plane A (above the background) and has low plane or high plane graphics (High plane always overlaps the sprites). All objects are in the foreground, but some objects can overlap the FG tiles too (like in sonic 2 where sonic passes a path swapper he can switch between high and low planes) So the platform is using this to be above the lava, right?

And the ring from debug mode also sets itself to high plane, but since its a sprite it only overlaps other sprites, like the platform. But there is a lava behind that platform, so the ring is behind the lava, and above the platform, thats why it uses the lava graphics.

How does it overlap the platform, but it doesn't overlap the lava or the high plane tiles? That is confusing.

Could you also explain how ShowVDPGraphics work? And there are a few stuff I dont understand, like the variable that has $8ADF and then gets moved to a6 ($F624) why is that?

[Hanoch]

Sorry for double posting but I didn't understand something.
Lets say I set a map plane A location, how big will it be? Does it end where the next one (ie map window) starts? Or maybe it depends on how much data I put there? Also what kind of data is in there (I assume enigma mappings)?

And, are the registers all you had to explain for vdp and that's it, from here on its just questions we ask?

Edited by Hanoch, 01 October 2010 - 09:46 PM.

[MarkeyJester]

Sorry for double posting but I didn't understand something.
Lets say I set a map plane A location, how big will it be? Does it end where the next one (ie map window) starts? Or maybe it depends on how much data I put there?

This register you should be concerned with...

Register 10 (90) - "Map Plane Size":

00WX 00YZ

W and X bits are used together respectively, and so are Y and Z bits.

Now the way to understand this is by seeing a graphical example:



The red and green squares represent the Map Planes, while the blue rectangle represents the screen, here's the rule, the screen can move anywhere within the plane area (The red square), if the screen crosses any of the red lines, the other side of the plane will present, basically looping/wrapping itself.

If the screen goes out one side, it'll enter the other side is the simplest way to put it.

This register controls how big the plane size is.

If WX is 00, then the vertical plane size is 32 cells/tiles big (32 x 8 pixels).
If WX is 01, then the vertical plane size is 64 cells/tiles big (64 x 8 pixels).
If WX is 11, then the vertical plane size is 128 cells/tiles big (128 x 8 pixels).

10 is prohibited for WX.

If YZ is 00, then the horizontal plane size is 32 cells/tiles big (32 x 8 pixels).
If YZ is 01, then the horizontal plane size is 64 cells/tiles big (64 x 8 pixels).
If YZ is 11, then the horizontal plane size is 128 cells/tiles big (128 x 8 pixels).

10 is prohibited for YZ too.

No matter what size you have the planes, they will always wrap in a loop should the screen advance out of the boundary area.

if for example WX is 00 and YZ is 01 then the map plane size is "Vertical x Horizontal" 32 x 64 tiles large (20 x 40 in hex), each tile's map is worth two bytes, so the simple math here is: "Vertical x Horizontal = S x 2 = A" (20 x 40 = 800 x 2 = 1000).

1000 bytes would be the size, so if you have the plane A location set to C000, the map area would be between C000 and CFFF.

Also what kind of data is in there (I assume enigma mappings)?

No, Enigma is the name given to a decompression algorithm used frequently by SEGA, it is used to reduce the size of data in the MC68 rom, this map data is decompressed from Enigma into a ram space somewhere and then sent to V-Ram as uncompressed, the VDP in the megadrive is not able to decompress Enigma's algorithm.

And, are the registers all you had to explain for vdp and that's it, from here on its just questions we ask?

It wouldn't be called "The VDP Questions Topic" otherwise =P

[Hanoch]

Does it also apply for the window plane (that was my main question)? Because what i'm trying to do is, load tiles in a vram address (or uncompressed from the ROM, but that depends on the limits) and use enigma mappings to arrange them on the screen and display them on the window map plane.

From what I understand:
A VRAM address has a bunch of tiles, and they all can be used in all map planes (that explains why when pausing in sonic crackers, the combi chain uses wrong graphics). Now when talking about VDP addresses (IE, plane A is in C000)
do you mean something like this:

move.l  #$C0000001,($C00004).l ; load the first row of 8 pixels in $C000-C007

please note, I might be wrong with the '1' at the end, I know 3 is positioning mode.

Edited by Hanoch, 01 October 2010 - 11:41 PM.

[MarkeyJester]

V-Ram location C000, in order to set the VDP to write to that location, you need to follow the instructions on "The first post" which i clearly made sure was the first thing to be explained. The resulting answer would be 70000003 for V-Ram location C000.

Also, all data in V-Ram, C-Ram and VS-Ram is uncompressed (This applies to everything including the window plane), if you have the data uncompressed in the rom, you can send it directly to V-Ram, if it is compressed in rom, you need to decompress it and then send to V-Ram.

[Selbi]

I had a few issues with converting VRAM values into VDP values, e.g. $A660 (VRAM) into $66600002 (VDP). While I can do it, it takes me like 5 minutes until I'm 100% sure that I did everything correct. MarkeyJester, the VDP hero of the scene, can do it within a few seconds and I asked him if he could do a little program which does all this for you (after all, it's not really an "I'll do everything for you"-program, because it just saves you a lot of time).

Link: http://mrjester.hapi...01_PBLC/VDP.rar

Using this program is pretty easy, but it was made in a rush and requires some information:

There's a text document with
VW A660 66600002
inside it.

That V, if it's a V, it's VRAM. If it's a C, it's CRAM. If it's an S, it's VSRAM.
That W, if it's a W, it's write. If it's an R, it's read.

You ALWAYS need to put a VRAM and a VDP adress if you don't to fuck anything up. In case you only want one value, you could either ignore one of it in the cmd, or just set it do 0, like so:
VW 0000 66600002

You also MUST capitalize the op-codes.

My personal thanks to MarkeyJester, as this program already saved me 15 minutes of senseless value converting. =)

[Hanoch]

Haha I was planning something similiar to that but I needed more time to learn C# and how to work with bits.
Good program though.

[Sonic master]

I have this code to display an image with a map
The tiles load fine and it works with plane a but I want to use plane b

		lea	($FF0000).l,a1

		lea	(level1map).l,a0 ; load mappings for Japanese credits

		move.w	#0,d0

		bsr.w	EniDec

		lea	($FF0000).l,a1

	move.l	#$40000003,d0

	moveq	#$27,d1

	moveq	#$1B,d2

	bsr.w	ShowVDPGraphics2

I changed this from

	move.l	#$40000003,d0

to

	move.l	#$60000003,d0

and it still does not work
also I am using basiegaxorz with some stuff borrowed from sonic 2 (show vdp grapics)

[MarkeyJester]

Ah now, this is because you haven't set the VDP display mode on, as I mentioned a few posts back, you can enable it by this register here:

Register 01 (81) - "Mode Register 2":

This register has four known functions:

0WXY Z100

W = enable or disable the "Display" (0 = disable/1 = enable)
X = enable or disable the "Vertical Interrupt" (0 = disable/1 = enable)
Y = enable or disable "DMA" (Direct Memory Access) (0 = disable/1 = enable)
Z = Vertical Display Mode (0 = V 28 Cell PAL or NTSC Mode/1 = V 30 Cell NTSC mode)

If W is disabled, non of the changes you make for display will present on screen (Though certain things like the palette still display).
If X is enabled, then while the interrupts are turned on via MC68 (move #$2300,sr) then the vertical blanking routines will function.
If Y is enabled, Direct Memory Access can be used (Will explain more about this later)
If Z is set 0, you have what the PAL screens usually get (shorter/wider screens). while set 1, you'll get NTSC stretched screen (This is an assumption based on the info I've read, may need confirming).

Of course, a more simpler way would be to follow the way Sonic Team enabled it, by using this:

		move.w	($FFFFF60C).w,d0
		ori.b	#$40,d0
		move.w	d0,($C00004).l

This will load data "81??" (with ?? being whatever it was set to) to d0, while the OR will set the display mode bit on, and then it's saved to the VDP address area.

[Sonic master]

Ah now, this is because you haven't set the VDP display mode on, as I mentioned a few posts back, you can enable it by this register here:

Register 01 (81) - "Mode Register 2":

This register has four known functions:

0WXY Z100

W = enable or disable the "Display" (0 = disable/1 = enable)
X = enable or disable the "Vertical Interrupt" (0 = disable/1 = enable)
Y = enable or disable "DMA" (Direct Memory Access) (0 = disable/1 = enable)
Z = Vertical Display Mode (0 = V 28 Cell PAL or NTSC Mode/1 = V 30 Cell NTSC mode)

If W is disabled, non of the changes you make for display will present on screen (Though certain things like the palette still display).
If X is enabled, then while the interrupts are turned on via MC68 (move #$2300,sr) then the vertical blanking routines will function.
If Y is enabled, Direct Memory Access can be used (Will explain more about this later)
If Z is set 0, you have what the PAL screens usually get (shorter/wider screens). while set 1, you'll get NTSC stretched screen (This is an assumption based on the info I've read, may need confirming).

Of course, a more simpler way would be to follow the way Sonic Team enabled it, by using this:

		move.w	($FFFFF60C).w,d0
		ori.b	#$40,d0
		move.w	d0,($C00004).l

This will load data "81??" (with ?? being whatever it was set to) to d0, while the OR will set the display mode bit on, and then it's saved to the VDP address area.

I got the problem solved layer a was hiding layer b
but now I am music sonic 1's show vdp grapics and the tiles are at at 128 tiles offset (80 hex)
i am currently trying to edit this code:

; ---------------------------------------------------------------------------
; Subroutine to	display	patterns via the VDP
; ---------------------------------------------------------------------------

; ||||||||||||||| S U B	R O U T	I N E |||||||||||||||||||||||||||||||||||||||


ShowVDPGraphics:			; XREF: SegaScreen; TitleScreen; SS_BGLoad
		lea	($C00000).l,a6
		move.l	#$800000,d4;I think I need to edit this?

loc_142C:
		move.l	d0,4(a6)
		move.w	d1,d3
loc_1432:
		move.w	(a1)+,(a6)
		dbf	d3,loc_1432;draws a row
		add.l	d4,d0
		dbf	d2,loc_142C;go to next row
		rts	
; End of function ShowVDPGraphics

EDIT:
fixed it myselft like this

; ---------------------------------------------------------------------------
; Subroutine to	display	patterns via the VDP
; ---------------------------------------------------------------------------

; ||||||||||||||| S U B	R O U T	I N E |||||||||||||||||||||||||||||||||||||||


ShowVDPGraphics:			; XREF: SegaScreen; TitleScreen; SS_BGLoad
		lea	($C00000).l,a6
		move.l	#$800000,d4

loc_142C:
		move.l	d0,4(a6)
		move.w	d1,d3
loc_1432:
		addi.w	#$80,(a1); add to offset tiles
		move.w	(a1)+,(a6)
		dbf	d3,loc_1432
		add.l	d4,d0
		dbf	d2,loc_142C
		rts	
; End of function ShowVDPGraphics

edit2:
better sulution that does not glitch

		lea	($FF0000).l,a1
		lea	(titlemap).l,a0 ; load mappings for Japanese credits
		move.w	#$80,d0;offset in tiles (hex)
		jsr		EniDec

edit3:
How do you clear this area of the vram

Edited by Sonic master, 17 January 2011 - 08:02 PM.

[Hanoch]

I watched a few genesis games on youtube with outstanding 3D effects (Virtual Racing). And I assume its also possible in sonic? Not to mention, if genesis cant do what nintendoes, mostly the super FX stuff, then why not move some engines to super nintendo?

Anyway I relised that to stretch/skew stuff (like the water in ghz) you need to find the number of lines, and the first line will move right a few pixels per frame while the last line will move left the same value of pixels per frame, reversed.
The lines in between will just decrease the pixels per frame value by an amount untill the middle where it reverses stuff.

This makes me wonder, what would it take to make this thing apply on sprites? I know you can just build a bunch of objects like the chain platform object and use obj15 code as a referrence, but is there a more efficient way that takes less object space?

Edited by Hanoch, 23 January 2011 - 06:06 PM.

[OrdosAlpha]

The Super Famicom has a slower CPU, so any Mega Drive engine, when ported, wouldn't run at the same speed as it does on the Mega Drive. So, why bother?
Plus, Virtua Racing used more than the MD, it used the Sega Virtua Processor on cart to handle the polygon to 8x8 tile generation.

[SpirituInsanum]

I have a question regarding this:

You probably noticed it before, that square in the top-right corner. This is in the original s1, it can be bigger or smaller.

Is the "map plane" 's wrapping system causing this glitch?

[MarkeyJester]

I "believe" it's draw code specific, Sonic 1 calls it's level drawing routine after the DMA transfers during the vertical blanking interval (V-Blank), it's possible that it isn't fast enough to write those last few tiles before the end of the screen's V-Blank. Of course, this is only a theory on my part, being the only one that makes sense, so feel free to correct me if there happens to be a more valid reason.

[SpirituInsanum]

Like I could correct you on these matters xD

Well, I more or less understand it's related to how fast the tiles are being loaded, but what I mean is this:

The tile in the left circle, which isn't being used anymore, appears to the right, but before the right tile is loaded?

I'm asking this because, at first, I thought the top-right chunk wasn't loading fast enough, but since it's happening with your "sonic 1: two-eight" as well, I was probably wrong about this being related to chunks, since 128 chunks should load faster than 256 chunks. So the problem wouldn't lie in chunk loading, but rather in the tile loading routines (LoadTilesAsYouMove in Hivebrain's disassembly).

It seems there are a few more things in s2's equivalent routine, as well a several other differences, which I thought could be optimizations to avoid this problem.

[TmEE]

That problem is most likely relating to what Markey told. One solution would be to process playfield stuff before some of game logic related things, or scroll after all tiles are loaded... just throwing out ideas ^^

TMS9918 is the VDP that SMS VDP is based on, its not the one in MD... MD has Yamaha YM7101 in it

[SpirituInsanum]

Still no luck with scrolling only when the pattern load cues are empty

Would it mean the game is not even trying to load those tiles soon enough?

Btw, "LoadTilesAsYouMove" is part of the "v_int" routine, I never doubted Markey was right, just trying to find which part of it is the problem ^^

What I mean with that picture is that the engine could be loading tiles that are too close on the right and too far on the left. Because it's redrawing the map plane, right? (that's how I understand the "Register 10 (90) - "Map Plane Size"" part on the previous page, but I could be wrong)