Sega Genesis Dev Kit (SGDK)
Moderator: Stef
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
Just an update for the Window plane memory stuff. I tried the suggested changes now the Window plane doesn't appear correctly. The Goplanes status bar is gone. If I extend the window to the entire screen, it's just random memory.
It could just be something on my side, too. Just wanted to let you know. I'll revert the changes until you run your own tests, Stef.
It could just be something on my side, too. Just wanted to let you know. I'll revert the changes until you run your own tests, Stef.
Stef wrote:djcouchycouch wrote:what's the value used for WPLAN in VDP_Init()? You didn't change anything else?Stef wrote: So WPLAN will be set to 0xA900 to not conflict with sprites nor hscroll.
I modified the vdp.h like this :
Code: Select all
#define WPLAN 0xA900 #define HSCRL 0xB800 #define SLIST 0xBC00 #define APLAN 0xC000 #define BPLAN 0xE000 ... /** * \def TILE_SPACE * Space in byte for tile in VRAM. */ #define TILE_SPACE WPLAN
and the VDP_Init() :
This is the only changes i made.Code: Select all
void VDP_init() { ... regValues[0x00] = 0x04; /* reg. 0 - Disable HBL */ regValues[0x01] = 0x74; /* reg. 1 - Enable display, VBL, DMA + VCell size */ regValues[0x02] = APLAN / 0x400; /* reg. 2 - Plane A =$30*$400=$C000 */ regValues[0x03] = WPLAN / 0x400; /* reg. 3 - Window =$2C*$400=$B000 */ regValues[0x04] = BPLAN / 0x2000; /* reg. 4 - Plane B =$7*$2000=$E000 */ regValues[0x05] = SLIST / 0x200; /* reg. 5 - sprite table begins at $BC00=$5E*$200 */ regValues[0x06] = 0x00; /* reg. 6 - not used */ regValues[0x07] = 0x00; /* reg. 7 - Background Color number*/ regValues[0x08] = 0x00; /* reg. 8 - not used */ regValues[0x09] = 0x00; /* reg. 9 - not used */ regValues[0x0A] = 0x01; /* reg 10 - HInterrupt timing */ regValues[0x0B] = 0x00; /* reg 11 - $0000abcd a=extr.int b=vscr cd=hscr */ regValues[0x0C] = 0x81; /* reg 12 - hcell mode + shadow/highight + interlaced mode (40 cell, no shadow, no interlace) */ regValues[0x0D] = HSCRL / 0x400; /* reg 13 - HScroll Table =$2E*$400=$B800 */ regValues[0x0E] = 0x00; /* reg 14 - not used */ regValues[0x0F] = 0x02; /* reg 15 - auto increment data */ regValues[0x10] = 0x11; /* reg 16 - scrl screen v&h size (64x64) */ regValues[0x11] = 0x00; /* reg 17 - window hpos */ regValues[0x12] = 0x00; /* reg 18 - window vpos */ ... }
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Just wondering if you saw a message i edited sometime ago, i had a look in the sega doc and found that :
<<The window use a fixed plan size of 32x32 tile in H32 mode and 64x32 in H40 mode so the size is not related to plan A...
So i have to keep enough place for the biggest possible window : 64x30 (we can ignore the 2 last tile lines as they are never visibles).
So WPLAN will be set to 0xA900 to not conflict with sprites nor hscroll.>>
But i will do some tests to verify that work.
By the way, what emulator you use to test GodPlanes ?
<<The window use a fixed plan size of 32x32 tile in H32 mode and 64x32 in H40 mode so the size is not related to plan A...
So i have to keep enough place for the biggest possible window : 64x30 (we can ignore the 2 last tile lines as they are never visibles).
So WPLAN will be set to 0xA900 to not conflict with sprites nor hscroll.>>
But i will do some tests to verify that work.
By the way, what emulator you use to test GodPlanes ?
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
I did see the message. The values I used are from your example, which seem to have the new values.
WPLAN doesn't just have 28 tiles visible? 64x28 instead of 64x30?
On second thought, if you think WPLAN would take too much memory, I'm okay with leaving the original values. Having the status bar at the top of the screen is not a deal breaker for me. Having more tile memory is more important than having the status bar at the bottom.
For the emulator, I use a modified GensKMod with some local changes to how the GUI is handled. I haven't tried any others since moving development to PC from Virtual Box on a Mac.
WPLAN doesn't just have 28 tiles visible? 64x28 instead of 64x30?
On second thought, if you think WPLAN would take too much memory, I'm okay with leaving the original values. Having the status bar at the top of the screen is not a deal breaker for me. Having more tile memory is more important than having the status bar at the bottom.
For the emulator, I use a modified GensKMod with some local changes to how the GUI is handled. I haven't tried any others since moving development to PC from Virtual Box on a Mac.
Stef wrote:Just wondering if you saw a message i edited sometime ago, i had a look in the sega doc and found that :
<<The window use a fixed plan size of 32x32 tile in H32 mode and 64x32 in H40 mode so the size is not related to plan A...
So i have to keep enough place for the biggest possible window : 64x30 (we can ignore the 2 last tile lines as they are never visibles).
So WPLAN will be set to 0xA900 to not conflict with sprites nor hscroll.>>
But i will do some tests to verify that work.
By the way, what emulator you use to test GodPlanes ?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Yeah, 28 in NTSC and up to 30 in PALdjcouchycouch wrote:I did see the message. The values I used are from your example, which seem to have the new values.
WPLAN doesn't just have 28 tiles visible? 64x28 instead of 64x30?
True but i prefer to offer the possibility by defaultOn second thought, if you think WPLAN would take too much memory, I'm okay with leaving the original values. Having the status bar at the top of the screen is not a deal breaker for me. Having more tile memory is more important than having the status bar at the bottom.
If you need more memory then you only need to change the WPLAN address (as it's the first in high VRAM memory and so define the TILE SPACE).
Ok,GensKMod correctly handle the window so this is not the problem...For the emulator, I use a modified GensKMod with some local changes to how the GUI is handled. I haven't tried any others since moving development to PC from Virtual Box on a Mac.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Stef changed the SGDK to separate out the joy type from the joy read value. Look at the h file for the new function to read the joy type.Mixail wrote:not working =(Code: Select all
#include "genesis.h" int main(){ VDP_setScreenWidth320(); VDP_setHInterrupt(0); VDP_setHilightShadow(0); VDP_setPaletteColor(PAL1, 15, 0x0888); VDP_setTextPalette(0); JOY_setSupport(PORT_1, JOY_SUPPORT_MENACER); while(1) { u16 value2 = JOY_readJoypad(JOY_1); switch (value2 >> JOY_TYPE_SHIFT) { case JOY_TYPE_MENACER: VDP_drawText("GUN", 20, 20);break;} VDP_waitVSync(); } }
What did I do wrong?
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
True but as far i remember i did not yet released this version so its method should work. Still i don't know if he uses an emulator to test its code...Chilly Willy wrote:Stef changed the SGDK to separate out the joy type from the joy read value. Look at the h file for the new function to read the joy type.Mixail wrote:not working =(Code: Select all
#include "genesis.h" int main(){ VDP_setScreenWidth320(); VDP_setHInterrupt(0); VDP_setHilightShadow(0); VDP_setPaletteColor(PAL1, 15, 0x0888); VDP_setTextPalette(0); JOY_setSupport(PORT_1, JOY_SUPPORT_MENACER); while(1) { u16 value2 = JOY_readJoypad(JOY_1); switch (value2 >> JOY_TYPE_SHIFT) { case JOY_TYPE_MENACER: VDP_drawText("GUN", 20, 20);break;} VDP_waitVSync(); } }
What did I do wrong?
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
Ah, I thought you pushed that out to the repo already. He's not printing enough info in his demo to determine what's going on. He needs to print which type of controller it's identifying, if any. Also, is his Menacer in port 1? I rather doubt it... most people have a pad in port 1 and the Menacer in port 2. That's probably the problem... setting the wrong port and reading the wrong joy. A Menacer in port 2 would be read using JOY_2.
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Oh i already pushed it ? Anyway i don't think much people use the latest pushed changes and prefer to directly use the archive.Chilly Willy wrote:Ah, I thought you pushed that out to the repo already. He's not printing enough info in his demo to determine what's going on. He needs to print which type of controller it's identifying, if any. Also, is his Menacer in port 1? I rather doubt it... most people have a pad in port 1 and the Menacer in port 2. That's probably the problem... setting the wrong port and reading the wrong joy. A Menacer in port 2 would be read using JOY_2.
If he indeed use my last changes then he should change its code and use the JOY_getJoypadType(...) method instead to retrieve joypad type.
Edit: ah yeah it looks like i already pushed it to the repository.
Last edited by Stef on Tue Oct 16, 2012 5:54 pm, edited 1 time in total.
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 710
- Joined: Sat Feb 18, 2012 2:44 am
-
- Very interested
- Posts: 2984
- Joined: Fri Aug 17, 2007 9:33 pm
-
- Very interested
- Posts: 3131
- Joined: Thu Nov 30, 2006 9:46 pm
- Location: France - Sevres
- Contact:
Yeah the font is stored at the end of vram tiles area.
Here's some constants which can help with vram tile organization :
TILE_MAXNUM :
maximum number of tiles that can be stored in vram without overwriting default tilemap / sprite list regions.
TILE_SYSTEMINDEX :
tile index for system tile (used internally for clear / fill operation).
TILE_USER and TILE_USERINDEX :
tile address / index for user tile in VRam.
TILE_USERLENGHT :
number of tiles available for user.
TILE_FONT and TILE_FONTINDEX
first tile address / index for font tile in VRam.
FONT_LEN :
number of character (and then tile) for a font.
Initially i wanted to reserve more memory for the windows plan in the next version, but we already don't have that much free so i think i will keep the current setting and then having restricted window (only displayable at top). Of course you can always override these parameters but you might take care about SGDK methods to not conflict then. If you don't use the internal font, you can use the font space to store 96 extra tiles, it's why the font is stored at the end of the region.
Also TILE_SPACE is hardcoded as 0xB000 where it should be hardcoded to WPLAN (which is the first no tile element in vram), the next version fix that.
Here's some constants which can help with vram tile organization :
TILE_MAXNUM :
maximum number of tiles that can be stored in vram without overwriting default tilemap / sprite list regions.
TILE_SYSTEMINDEX :
tile index for system tile (used internally for clear / fill operation).
TILE_USER and TILE_USERINDEX :
tile address / index for user tile in VRam.
TILE_USERLENGHT :
number of tiles available for user.
TILE_FONT and TILE_FONTINDEX
first tile address / index for font tile in VRam.
FONT_LEN :
number of character (and then tile) for a font.
Initially i wanted to reserve more memory for the windows plan in the next version, but we already don't have that much free so i think i will keep the current setting and then having restricted window (only displayable at top). Of course you can always override these parameters but you might take care about SGDK methods to not conflict then. If you don't use the internal font, you can use the font space to store 96 extra tiles, it's why the font is stored at the end of the region.
Also TILE_SPACE is hardcoded as 0xB000 where it should be hardcoded to WPLAN (which is the first no tile element in vram), the next version fix that.