Sega Genesis Dev Kit (SGDK)

[matteus]

Do you tested on SGDK 09.6c ? Does the code was working on previous SGDK version or is it the first time you try it ?

No the code has never worked with this set of images. It works with my hand drawn graphics but not the video captured ones.

[Stef]

If you try to display one of the corrupted image but alone (without playing the rest of the video), does it display correctly ?

[matteus]

If you try to display one of the corrupted image but alone (without playing the rest of the video), does it display correctly ?

Hey Stef,
I hope you got my PM with the link to the ROM regarding the image display issues?

Matt

[prophet36]

Hackaday mention SGDK in their write-up about my UMDK dev-cart (because the UMDK menu program was developed using SGDK).

[Stef]

Thanks for the advertising I posted a tweet about your UMDK as soon you announced the new version on the forum ! I would paid a lot to have one

[matteus]

Hackaday mention SGDK in their write-up about my UMDK dev-cart (because the UMDK menu program was developed using SGDK).

Fantastic!

[Mixail]

u16 JOY_readJoypadX(u16 joy);

A light gun returns the unsigned screen X coordinate. This is not calibrated;<br>
* Calibration is left to the game to handle. The value is -1 if the gun is not<br>
* pointed at the screen, or the screen is too dim to detect.<br>

How is calibrated?

[Stef]

I have to admit i have no ideas about it... Does that need calibration to start with ? I though it was returning "pixel" position (relative to HV counter).

[Chilly Willy]

Look for a pdf called "gen_lightgun.pdf" which explains everything about the lightguns on the Genesis. SGDK handles everything for you except for the gun calibration. Pages 6 and 7 explain how to convert the lightgun coord into a screen coord for the Menacer, and pages 10 and 11 do the same for the Justifier.

It's easy to see the values using the included joystick example from SGDK. When you use a lightgun with it, it shows the screen coords. So just plug in your gun, run the example, and point it at various parts of the screen. Nothing beats seeing the values with your own eyes to get a firm understanding of how the coords relate to the screen.

If you need any help, I've got two Justifiers and the Menacer. I was the one who added the lightgun support to SGDK (among other peripherals).

[KanedaFr]

...on font.h, it calls a libres.h
what it is ? since it didn't exist.....
...
last one,
if someone know how to fix this $*$ù$pmù:mùmmùm
gcc.EXE: *** couldn't allocate heap, Win32 error 0, base 0x640000, top 0x650000, reserve_size 61440, allocsize 65536, page_const 4096
11063285 [main] gcc 5080 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11
....

Edit by Stef: Sorry i did "editer" instead of "citer" and modified your message by mistake, some parts were lost :-/

[Chilly Willy]

I have to admit i have no ideas about it... Does that need calibration to start with ? I though it was returning "pixel" position (relative to HV counter).

A little more on this in general. While the guns basically do just return a position related to the pixel (it's just latching the horizontal and vertical counters, after all), there's no telling how good the gun was made. As such, the lens may be oriented a little different from gun to gun. So when the user aims at a point on the screen, he's aiming based on the gun sights, while the lens may be looking off a little in a random direction.

So you have two things that any light gun game MUST do: first, convert the counter values into a pixel; and second, have some kind of calibration screen. To calibrate the gun, you put up a target on the screen with a message telling the user to fire at the center of the target. A simple bulls-eye is fine. You then look at where the gun SAYS the user is aiming, and adjust it to be the center. It's best to have the user fire several times so as to take into account the user's ability to hold the gun steady. Maybe show the user where the gun thinks it's aimed based on the current average offset. The user can just keep firing until the spot matches the center of the target.

I really ought to make an example LG game to show some of these things. I was thinking of something like T2 where all the Terminators and things come straight at you out of the screen, except not Terminators... maybe orcs or zombies. I always did like those storm-the-castle games with orcs and zombies. Changing it from a sideways game to popping out of the screen would make a nice change.

[Stef]

Ok, that all make sense Thanks for clarifying !
Indeed having a cursor showing where the gun is actually aiming and then asking user to shoot a target until cursor and target match is a good method to do the calibration !

[Stef]

Sorry Kaneda i modified your message by mistake and lost the original one !
I can just reply to it now :

on font.h, it calls a libres.h
what it is ? since it didn't exist.....

It should be automatically generated by resource compilation but maybe i mess up (again) object compilation order and so you don't have it in time.

last one,
if someone know how to fix this $*$ù$pmù:mùmmùm
gcc.EXE: *** couldn't allocate heap, Win32 error 0, base 0x640000, top 0x650000, reserve_size 61440, allocsize 65536, page_const 4096
11063285 [main] gcc 5080 fork: child -1 - died waiting for longjmp before initialization, retry 0, exit code 0x100, errno 11

Definitely i also have the same problem and never been able to fix it. Seems to be random crash of GCC on win system :-/
By compiling severals time you get further and further until complete compilation but definitely that is really annoying...

[KanedaFr]

ah ah!
About GCC crash, it seems it related to what is already launched when you call it...
I found some details over the net, but since I'm not in GCC source code, I didn't understand everything

with your edit, you deleted the
what about the warning on strcmp ?
which is indeed resolved including "-fno-builtin"
This warning shouldn't occur if you use SGDK included makefile but since I use my own, I had some update to do

It took me 1hour to update to last SGDK, because of lot of refactoring ...
anyway, it's now done

[alko]

Hi.

I do not quite understand in English, but still try to ask a question.
Since on the Russian-speaking community nobody can help to SGDK.

In general, the output text and tiles (4bpp bitmap) I learned. But stalled on the withdrawal of sprites. Here is my code:

Code: Select all

#include <genesis.h>


struct genresTiles
{
		u16 *pal; 		//pointer to pal data
		u32 *tiles;		//pointer to tiles data
		u16 width;		//width in tiles
		u16 height;		//height in tiles
		u16 compressedSize; //0 in this demo, more coming soon
};
extern struct genresTiles title;

struct genresSprites
{
		u16 *pal; 		//pointer to pal data
		u32 **sprites;		//pointer to sprites data
		u16 count;		//nb sprites
		u16 width;		//width of each sprite in pixels
		u16 height;		//height of each sprite in pixels
		u16 size; 		//since we use width/height in pixel, useful info on sprite size
						//TODO : size is not SGDK compliant, you need to use size>>8
						//		will be fixed in coming release
};
extern struct genresSprites bat1;


#define TILE1	1

int main( )
{
SpriteDef mySprite;
	
	u8 frame = 0;

	VDP_setPalette(PAL1, title.pal);

	// load tiles in VRAM
	//  arg0 = tiles data
	//  arg1 = index for first destination tile
	//  arg2 = number of tiles to load
	//  arg3 = use DMA (1) or not (0)
	VDP_loadTileData(title.tiles, TILE1, title.width*title.height, 0);
	
//	VDP_fillTileMapRectInc(BPLAN, TILE_ATTR_FULL(PAL1, 0, 0, 0, TILE1), 0, 0, title.width, title.height);
	
	VDP_resetSprites();
	VDP_setSprite(0, 0, 0, bat1.size>>8, TILE_ATTR_FULL(PAL1,1,0,0,TILE1), 1 /* 0 */);

        
        // define the sprite (using a _spritedef to easily make Sonic move later)
   // define the sprite (using a _spritedef to easily make Sonic move later)
        mySprite.posx = 40;
        mySprite.posy = 40;
        mySprite.size = bat1.size>>8;
        mySprite.tile_attr = TILE_ATTR_FULL(PAL1,1,0,0,1);
        mySprite.link  = 0;
        VDP_setSpriteP(0, &mySprite);

	
	
	while(1)
	{
	       VDP_setSpriteP(0, &mySprite);
	  VDP_updateSprites();
	VDP_waitVSync();
	}
	return 0;
}

Сompiled without errors.

Here is a resource file:

Code: Select all

BITMAP title "data/title.bmp" 0
SPRITE bat1 "data/bat.bmp"  56 16 0

title.bmp - 4bpp bitmap.
bat.bmp too - 4bpp bitmap. (56x16 pixels)

"title.bmp" is drawing, but "bat.bmp" - do not draws.