SpritesMind.Net

help!!!

are you testing on emulator or real hardware ?
emulator menacer support is not perfect so you should test on real hardware.

Tell as it is correct to cause menacer (Gun). Give me sourc code. Give me source code.

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.

Stef wrote:

djcouchycouch wrote:

Stef wrote: So WPLAN will be set to 0xA900 to not conflict with sprites nor hscroll.

what's the value used for WPLAN in VDP_Init()? You didn't change anything else?

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() :

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 */

    ...
}

This is the only changes i made.

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 ?

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.

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 ?

djcouchycouch 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?

Yeah, 28 in NTSC and up to 30 in PAL

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.

True but i prefer to offer the possibility by default
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).

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.

Ok,GensKMod correctly handle the window so this is not the problem...

Mixail wrote:

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();
    }
}

not working =(

What did I do wrong?

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.

Chilly Willy wrote:

Mixail wrote:

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();
    }
}

not working =(

What did I do wrong?

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.

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...

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.

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.

Oh i already pushed it ? Anyway i don't think much people use the latest pushed changes and prefer to directly use the archive.
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.

I just updated my repo to the latest (rev 73) and it is indeed pushed to the repo. So he needs to use the new JOY_getJoypadType() to get the type instead of the old way.

Is the built-in font stored at the very end of the tile memory? My first attempt at adding the zeppelin to the game reveals that I'm very quickly running out of room in the VDP.

The font is a bit weird... it's made to END at 0xB000 in the VRAM, and it works backwards however long the font is. The default font is 96 characters (tiles) long, so the bottom address is 0xB000 - 0x60*0x20 = 0xA400.

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.