Page 19 of 23

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Fri Feb 22, 2019 12:10 pm
by DCGX
:D

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Fri Feb 22, 2019 4:25 pm
by Ian Micheal
It look's nice but this could be ported .. major problem state what your using all the spec's of the game etc memory lib's used etc etc .. C++ on the free dev tool's is not really fully working ive found.. ether is openGL many other lib's are subset's.. if you give me a full run down of what is needed to compile this.. i could tell you the work needed to port this.. ive been porting coding for dreamcast since 2001.. if that give you an idea

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Sat Feb 23, 2019 11:53 am
by shadowgangs
Hi Ian;

Thank you for proposing to help. I will for sure need it when I resume the Dreamcast port.

The situation on the Dreamcast port of Shadow Gangs is that I had one simple demo level of the game loading and playing on the NullDC emulator.
It's using OpenGL, Paletted 8 bit mode (256 colors), and 640*480 resolution, mp3 sound (this one I am not sure it will be stay mp3, because of the big processing overhead, so in the end, big chance it will be CD Audio tracks).

The only real issue I am concerned about is memory, especially the video memory, system memory should be ok.
I think with KOS, I had only around 4mb free to play with (OpenGL).

This will be an issue with loading all the sprites and level art on the Dreamcast, so I forsee some cuts here and there will apply to make a normal level fit into Vram.

When I resume work on the Dreamcast, I will ask you for help, questions etc... if you don't mind.

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Sun Feb 24, 2019 3:23 pm
by Roel
I really like that blue sky! :)


To add my 2 cents as a developer:

> Paletted 8 bit mode (256 colors)
There are several ways to do that on the DC. :)

> mp3 sound
You're right, CD audio is a better choice. Or you could use a very light-weight compression. I use ADPCM-compressed audio myself (forgot which flavour), as do many official games (ADX).

> The only real issue I am concerned about is memory, especially the video memory, system memory should be ok.
Yes, the VRAM fills up quickly. But if you have enough free system RAM, you can swap textures as needed. Moving data from RAM to VRAM is very fast. If not, it's probably worth considering to get rid of the OpenGL dependency for your DC port.

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Sun Feb 24, 2019 5:29 pm
by shadowgangs
Hi Roel;

Thanks for the reply.

For the palettised mode, I am following the DC emulation website tutorial on it.
Is there other options for this mode?, The one I used I remember it being 8 bit, with 4 palettes of 256 colours each.(Looked great in null DC)
Other modes, i tried either took too much memory, or were aweful looking (the Power VR compressed one especially).

Thanks for the ADX adpcm, I didn't know about. I'll have a look at it once I resume DC work again.

For the Video ram, the problem with the Dreamcast I found is the deferred rendering, which needs all the assets that are rendered in a frame to be in VRAM at once.
It's not like, draw sprite, remove it from Vram, put a new sprite in vram, draw it then remove it, then draw again etc...this way doesn't seem to work on the Dreamcast, because of the deferred rendering, that's what I beleive is happening?

So if in a screen, there is say 5 different enemies at the same time + the backgrounds, then all these need to be at the same time in VRAM.

This would mean, I will need all the level, with all the enemies in VRAM when a level is running.

(I could not use system to vram, because all the enemies can be at once in a frame, and need to rendered)
Please let me know if I am saying wrong things here.

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Mon Feb 25, 2019 4:29 am
by Roel
shadowgangs wrote:For the palettised mode, I am following the DC emulation website tutorial on it.
Is there other options for this mode?, The one I used I remember it being 8 bit, with 4 palettes of 256 colours each.(Looked great in null DC)
Other modes, i tried either took too much memory, or were aweful looking (the Power VR compressed one especially).


The global palette mode (the one you mentioned, with 4x256 colours) is usually fine.

An alternative method is by using VQ-compressed textures, but not compressing them. The way VQ compression works, is that each byte in the texture represents 4 pixels, which are stored in a lookup table. If you store 4 identical colours in each of the lookup table's entries, it essentially becomes a colour palette. With only half as many bits as the global palette, the colours are not as good, but the advantage is that there is no limit to the number of palettes. You can also use both methods together.


shadowgangs wrote:For the Video ram, the problem with the Dreamcast I found is the deferred rendering, which needs all the assets that are rendered in a frame to be in VRAM at once.
It's not like, draw sprite, remove it from Vram, put a new sprite in vram, draw it then remove it, then draw again etc...this way doesn't seem to work on the Dreamcast, because of the deferred rendering, that's what I beleive is happening?


You wouldn't want to do that anyway, it's very bad for performance.


shadowgangs wrote:So if in a screen, there is say 5 different enemies at the same time + the backgrounds, then all these need to be at the same time in VRAM.

This would mean, I will need all the level, with all the enemies in VRAM when a level is running.

(I could not use system to vram, because all the enemies can be at once in a frame, and need to rendered)
Please let me know if I am saying wrong things here.


You don't need all of that to be in VRAM all the time. For each rendered frame, you only need to have those graphics in VRAM that are visible in that particular frame, which is only a small subset of the total. In most cases, they will be mostly the same as in the previous frame. You only need to copy the graphics that are new in the current frame, which is usually a small enough number to not noticeably impact performance (at least in my experience).

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Mon Feb 25, 2019 5:58 am
by shadowgangs
Thanks a lot :)

I see now, spritesheet in system ram, and only current frame to render in vram.

How do you upload a single frame from a spritesheet in system ram to vram using OpenGl? :)

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Mon Feb 25, 2019 7:46 am
by Roel
Not necessarily just one frame. Just copy however much of your sprite sheet is convenient.

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Mon Feb 25, 2019 1:52 pm
by shadowgangs
Roel wrote:Not necessarily just one frame. Just copy however much of your sprite sheet is convenient.

Yes, I see.

Is this selective load to Vram from a spritesheet possible with OpenGL for Dreamcast?
I am using pvr spritesheets, and do these calls:

glGenTextures
glBindTexture
glTexImage2D (is this one that uploads to vram ?)

glTexImage2D works on PVR spritesheet

glTexImage2D(GL_TEXTURE_2D,
0,
GL_RGBA,
texW, texH,
0,
GL_RGBA,
texFormat | texColor,
TEX0, iPaletteIndex);

The TEX0 is the PVR content in sys ram.

Can this call be adapted to load individual frames instead? for example using a offset from TEX0?

Just want to see if this is actually how selective frame uploads are/can be done using this method.

Re: (Kickstarter) Shadow Gangs: 80's ninja arcade action revival

Posted: Tue Feb 26, 2019 4:09 am
by Roel
I have no experience with OpenGL myself, but if your textures are stored in the DC's native format (which they should be), you should be able to address them in quarters. IIRC, the order is a mirrored 'N'. So the first quarter of the data contains the top-left quarter of the texture, followed by the bottom-left one, then the top-right one and finally the bottom-right one.

Personally I just stick to 256x256 textures, which I find are small enough to decompress and copy quickly. If a sprite or other image is too big to fit on such a small texture, it is distributed over multiple textures.