Dreamcast-Talk.com

Ian Micheal wrote:have to mod every txt file every postion file it's a lot of work to do so the game not boot course all the level files have postion for bigger size

at 480x272 boots normal but not centered screen. It's curious changing different resolutions video.txt before modding gifs to 320x240 the game plays entire but tiny centered screen, so what only would have to do in this case is to make screen bigger, but after trying 5 different versions no good, sorry if I try easier ways . If I hav to mod all txt.files anyway it will take more time...

Ro Magnus Larsson wrote:

Ian Micheal wrote:have to mod every txt file every postion file it's a lot of work to do so the game not boot course all the level files have postion for bigger size

at 480x272 boots normal but not centered screen. It's curious changing different resolutions video.txt before modding gifs to 320x240 the game plays entire but tiny centered screen, so what only would have to do in this case is to make screen bigger, but after trying 5 different versions no good, sorry if I try easier ways . If I hav to mod all txt.files anyway it will take more time...

Yes Txt files and postion of sprites all needed changing when converting down to 320x240 nothing scales..It's pain to do and you need to work out the math to all the levels and scale that to match..


Not possible to scale 480x272 to fullscreen on the fly that would use cpu power to do so.

Just changing any of the images will not make a working game..

DreamBOR project is dead?

Dreamkazt wrote:DreamBOR project is dead?

No why would you say that..I have other projects not that much to add to this if you work with in ram limts you can make very good games..
I will add custom theme-able vmu icon for people.. after tmnt project..

Hi Ian ,I am still using and testing the latest version you made of dreambor and in my tests I saw some problems with panels and bg layers, as for every layer you add to a stage more ram it consumes and slower the game becomes .
Also when using strange resolutions as in the example, instead of centering the game, what it does is to dwarf the visible window and adds garbage bars on the sides.

Here I leave an example with one that I had been testing called Balacera Brothers where its native resolution is a rare widescreen at 420x240.
Tested in real hardware using gdemu and the 7.1 dreambor version.
(in the Wii openbor the image is correctly stretched covering the whole screen)

https://youtu.be/Ru0yBOMtgjU

Dakangel wrote:Hi Ian ,I am still using and testing the latest version you made of dreambor and in my tests I saw some problems with panels and bg layers, as for every layer you add to a stage more ram it consumes and slower the game becomes .
Also when using strange resolutions as in the example, instead of centering the game, what it does is to dwarf the visible window and adds garbage bars on the sides.

Here I leave an example with one that I had been testing called Balacera Brothers where its native resolution is a rare widescreen at 420x240.
Tested in real hardware using gdemu and the 7.1 dreambor version.
(in the Wii openbor the image is correctly stretched covering the whole screen)

https://youtu.be/Ru0yBOMtgjU

#320x240 there is no SDL_GFX stretch never was with any openbor on dc it would mean scaling in software and be 2x as slow..
Every thing has to be 8bit pal and 320x240.. Might be some of asm is causing some faults in layers i will have to look

No cpu power to do software stretching on dc.. You have to scale it your self off the machine to fit 320x240 there is no code for it in the render..

Dreamcast is 320x240 fullscreen or 640x480 fullscreen nothing inbetween sorry to say .. Been testing ripfires new ones and they all run near 60fps but there all proper converted 8bit pal 320x240..with out pvr hardware scaling and opengl it's never going to be using more then 256 colours..
Major problem opengl uses more ram then this so have even smaller levels ..

There is only 13mb of ram to use and it never will free whole game every level every sprite has to fit into 13mb total..

Pretty much have to think of it like a console in that limit .. I added the other pal 16,32 but there not use-able like the team said and drop all support on dc..

ripfie has script that lowers memory use for Dreambor and it works but you cant free any ram with this engine it holds all scripts in protected memory.. The known command is it once it's known it keeps it added.. same thing happens on pc ..

Anytime a sprite is added that's it goes into the script if you take away that sprite the script crashes.. Got think as well scripting engine here is much older talking version 4 something many new commands in 5 and 6 dont work or cause problems..

NO res other then 320x240 or 640x480 will work cant use any other you have to convert that by hand your self off dc .. Matter of the dc could not do that scaling in software and even be use-able..

Ian Micheal wrote: NO res other then 320x240 or 640x480 will work cant use any other you have to convert that by hand your self off dc .. Matter of the dc could not do that scaling in software and even be use-able..

Ok, only those resolutions are available on dreamcast, their anamorphic counterparts arent supported i suposse (427x240 and 856x480) or their cropped widescreen versions (320x180 and 640x360)

Ian Micheal wrote: Major problem opengl uses more ram then this so have even smaller levels ..
There is only 13mb of ram to use and it never will free whole game every level every sprite has to fit into 13mb total..

it would be better the sacrifice , more stability with smaller and well optimized levels

Ian Micheal wrote: Pretty much have to think of it like a console in that limit .. I added the other pal 16,32 but there not use-able like the team said and drop all support on dc..

i use it a lot, for me is a welcome addition and i thank you for that

Ian Micheal wrote: you cant free any ram with this engine it holds all scripts in protected memory..
Anytime a sprite is added that's it goes into the script if you take away that sprite the script crashes.. Got think as well scripting engine here is much older talking version 4 something many new commands in 5 and 6 dont work or cause problems..

Maybe the only scripts that are nedded at all times being loaded in memory should be the ones in the "update.c" and "updated.c" files, other than that are dispensables or reloaded when needed.

Here are another game examples, usign as a base a heavy edited balacera game:

This use the capcom arcade resolution 384x224 at 16bits, only one multi layered level with a big panel that adds 5mb because of the layers, one character with scripts that adds 2 or 4 mb and one remanent boss to test the game and all of those ocuppied nearly the full dreamcast memory.
https://youtu.be/QlpG6bAIDHk

This has no scripts at all, use the standard 320x240, no layered level but only the background and 3 small panels that can be reused and only the main character and an incomplete enemy; the game uses lesser ram than before.
https://youtu.be/VreWOR4yIVY

As you can see there is a lot of differences between the two in performance and presentation.

No only 320x240 etc set res in sdl for dc cant have anything other then 320x240 or 640x480 set the above in video.txt to 8 bit pal above would be 60fps
big panel are a no no many abused the engine on pc because they can on pc or wii or something with more ram and cpu speed..
Where talking all software rendering here DC cant do anything software rendering and do the colour decoding in cpu time and music
and decoding of png or gif at the same time .. Other then using 8bit pal your stuffed ..

Max fps on 16bit pal is 18fps max with dips to 10fps..

I did debug and profile 16bit pal is cpu bound using 100% of the sh4 cpu at 15fps sadly ...
No optimizing i can do for this other then limit to 256 colour which is what 8bit pal mode does
see the example games one was 32bit mode now running 60fps other was 16 bit mode and is now 60fps

both before where 10fps to 15fps..

There now using half the ram as well more colours more ram use..

When i added the 16/32 modes it was just proof they work but the openbor team was correct

You would not want the opengl version on dc where talking max 6mb for the whole game..

Not like you cant do complete proper long games at 60fps just have to work to it's limit
like it was a console..

At this limit you have more then megadrive or neogeo machine..

Dreambor memory saving script by ripfire




Example
4 layers 320x240 proper converted 60fps
https://streamable.com/e70w46


Example 2
https://streamable.com/wry0bn 60fps steady

Example3
https://streamable.com/k9ldzr now 60fps

cant use 16 bit pal mode

# 8bit 60fps
#
# 16bit 10 to 15fps double memory use
#
# 32bit 5 to 10 fps even more

video 0
colourdepth 8bit

course panels cant be as big as on pc

What I'm going to do is move this to gcc9.3 and we might see some better things with math and speed..

I mean it's right in the src same for dc only free when you exit the whole program so dont see the use anyways

Most compatible and less memory use versions i did is 6.8 below
Still need to convert and use onlt 320x240 and 256 color mode for 60fps and the most memory use-able..
This one here will have up to 2mb more free at any one time..