Sprite problem Gens & Fusion

Nainain · Post by **Nainain** » Sat Oct 11, 2014 3:41 pm

Hi,

I ve a different rendering between gens & fusion with this code :

#include <genesis.h>
u16 cycleId = 0;

const u32 sweepTiles[8]=
{
		0x00000000, 
		0x00000000,
		0x00000000,
		0xFFFFFFFF,
		0x00000000,
		0x00000000,
		0x00000000,
		0x00000000,
};

#define SWEEP_SPRITE_NUM 40
SpriteDef sweepSprite[SWEEP_SPRITE_NUM];


void sweepMake(u16 pal,u16 x, u16 y){
         u8 i = 0;
         for(i = 0; i < SWEEP_SPRITE_NUM; i++){
               sweepSprite[i].posx = x + (8 * i);
               sweepSprite[i].posy = y;
               sweepSprite[i].size = SPRITE_SIZE(1,1);
               sweepSprite[i].tile_attr = TILE_ATTR_FULL(pal,1,0,0,1);
               if( i == SWEEP_SPRITE_NUM - 1 ){ sweepSprite[i].link = 0;} else{
                   sweepSprite[i].link = i + 1;
               }
         }
}

int main(){
    VDP_setScreenWidth320();
    sweepMake(PAL0,0,50);
    u16 tileIndex = TILE_USERINDEX;
    VDP_loadTileData( (const u32 *)sweepTiles, 1, 4, 0); 
                         
    while(1){
             u8 i = 0;for(i=0; i < SWEEP_SPRITE_NUM; i++){
                VDP_setSpriteP(i, &sweepSprite[i]);
             }
            VDP_updateSprites();                                          
            cycleId++;
            VDP_waitVSync();
    }        
}

I dont know why ...
here is a screenShot:
https://dl.dropboxusercontent.com/u/863 ... Fusion.png

Thx for u're help

Chilly Willy · Post by **Chilly Willy** » Sat Oct 11, 2014 6:25 pm

Different emulators render in different ways. One might render the entire screen once each vert blank, while another might render one line per horz blank. The second tends to be more accurate, but consumes more time. However, it is not entirely accurate either. You would need an emulator that renders every pixel in step with the processor and VDP to get a really accurate display... which would require a monster PC to run. It sounds like what you're trying to do is something that doesn't emulate well. You might also try what you're doing on real hardware and see if it looks anything like what you want. If it doesn't work on real hardware, you're doing it wrong.

Stef · Post by **Stef** » Sat Oct 11, 2014 9:23 pm

Hi Nainain,

Nice to see ya there

Looks like you are tying to display a simple line, why just don't use the SGDK bitmap engine for that ? It's really better to use it when you want to draw lines or manipulate pixels in general...

djcouchycouch · Post by **djcouchycouch** » Sat Oct 11, 2014 9:51 pm

I was going to mention that maybe VDP_updateSprites() should be called after VDP_waitVSync() because that's what it looks like in my code. But looking at the examples, it looks like I'm wrong! My engine foundation might have a crack in it.

I've always thought it was:

[run your code] // run the game when the VDP draws the frame
[wait for vsync] // wait until the frame is done being drawn
[update the vdp] // update all the sprite positions, update plalettes, run DMA stuff, etc.

Stef · Post by **Stef** » Sat Oct 11, 2014 10:14 pm

If you are speaking about this example :
https://code.google.com/p/sgdk/source/b ... src/main.c

It uses the new SGDK sprite API which does all operations in a cache and automatically update hardware VDP sprites during VBlank so you don't have to deal with it yourself.
Actually i recommend to use the new sprite engine almost every time, it's far much easier as it automatically handle meta sprite for you, animation, VRAM allocation... The only exception is when you have many sprites in which case it may be too slow (need some optimization).

Mask of Destiny · Post by **Mask of Destiny** » Sun Oct 12, 2014 12:55 am

It looks like you're hitting the 20 sprite per line rendering limit. I thought Gens implemented that, but maybe not. If you want to persist with this approach for drawing the line, you need to use wider sprites to fill the whole line. As Stef suggested, this probably isn't the best way to achieve your goal, but it would be a bit easier if we knew your ultimate goal.

Chilly Willy wrote: You would need an emulator that renders every pixel in step with the processor and VDP to get a really accurate display... which would require a monster PC to run.

<shamless plug>BlastEm can effectively achieve that on a single core first generation 1.6GHz Intel Atom. The key observation is that the VDP doesn't do anything that interferes with the 68K unless the 68K initiates it. So I can run the 68K core until it tries to interact with some of the rest of the hardware and then I can catch the rest of the system up to that particular cycle. I can't achieve perfect Z80/68K interaction this way (though I have a possible solution), but I can cover the important cases (Z80 getting blocked by VDP DMA for instance).</shameless plug>. That said, there are general accuracy bugs that make it deficient compared to other emulators in some areas and it's mostly limited to 64-bit versions of Linux and certain BSDs in the current release. So it might not be the best choice depending on your situation/setup.

Chilly Willy · Post by **Chilly Willy** » Sun Oct 12, 2014 5:28 am

Mask of Destiny wrote: <shamless plug>BlastEm can effectively achieve that on a single core first generation 1.6GHz Intel Atom. The key observation is that the VDP doesn't do anything that interferes with the 68K unless the 68K initiates it. So I can run the 68K core until it tries to interact with some of the rest of the hardware and then I can catch the rest of the system up to that particular cycle. I can't achieve perfect Z80/68K interaction this way (though I have a possible solution), but I can cover the important cases (Z80 getting blocked by VDP DMA for instance).</shameless plug>. That said, there are general accuracy bugs that make it deficient compared to other emulators in some areas and it's mostly limited to 64-bit versions of Linux and certain BSDs in the current release. So it might not be the best choice depending on your situation/setup.

Neat! I aught to try BlastEm. Sounds like just the thing for my new PC.

r57shell · Post by **r57shell** » Sun Oct 12, 2014 8:53 am

Check "Sprite Limit" setting in gens, it's somewhere in Graphics.

Nainain · Post by **Nainain** » Sun Oct 12, 2014 10:08 am

Hi everyone,
Thanks for your answers

Stef, in my project and in my mind, it's not a simple static line ...
I ve make this simple code for more explicit

it's easier to find me a solution if i explain what i want to do really
But i don't want us to do a goal code for me ...(not fun)

I ve quickly tried the SGDK bitmap engine, but two things:
>My VDP_drawImage functions render nothing (Perhaps normal in this "BMP mode")
>And the 256x160 resolution is too small

This mode is great (cube & particles samples is awesome), but for my current effect i think i don't can use this (so,i need a scrolling background in same time)

Stef · Post by **Stef** » Sun Oct 12, 2014 8:21 pm

Indeed you can't have full resolution with the bitmap engine due, mainly because of the memory limitation (i need double buffering in main ram) and also to improve the maximum frame rate by using extended blank.
When you are in bitmap mode you have to use the BMP_xxx method as BMP_drawBitmap(..) to draw an image (you have to use the BITMAP resource type instead).