If you look at my 3DO homebrew games,
you can see they have some issues compared to, let's say, commercial games.
That's because the provided examples are pretty poor and the documentation doesn't really help either.
For example, 3DO knows that their soundplayer freezes the cpu but they are telling the devs that
if they want know that doesn't freeze the console, they have to do themselves...
That's probably the first time i'm seeing a video game manufacturer providing an incomplete devkit !
So things i need help for :
A better Sound Player
DONE
Simply use Burgerlib.
See this post to understand how to use it.
A way to reuse existing resources
DONE
It turns out 3DO has a function, DrawAnimCels, that can draw Cels on screen without reloading another copy !
Check out Evil Australians's source code if you want to see it in action.
Saving/Loading to NVRAM
DONE
See this
The code for that is huge so i will release it later.
Burgerlib could provide a solution to that but it's way too low-level...
Perhaps there's a simple solution to that.
If at least we could have that, i (and others) will be able to provide better games.
(as well as improving on existing one !)
What's next would be nice to have too but not critical.
Better pixel drawing routines
Optimus made some drawing routines : https://bitbucket.org/Optimus6128/3dold
A smaller example would be nice though
Things that can be improved
Things that can be improved
Last edited by blabla on Sat Feb 11, 2017 9:19 pm, edited 4 times in total.
Re: Things that can be improved
To tell the thruth the actual SDK seems easy enough to me, altough it's true I'm a bit oldschool
Anyway, creating a wrapper library sounds good. Currently I don't have too much free time, but if you need help in something specific I could help
At least official developers had debugging tools, I can live with bugs, but give me a debug console at least!
Anyway, this is something I can check.
http://hackipedia.org/Platform/3D0/html ... #XREF27076
Lib3DO has a lot of useful wrapper functions:
http://hackipedia.org/Platform/3D0/html ... Ofrst.html
Anyway, creating a wrapper library sounds good. Currently I don't have too much free time, but if you need help in something specific I could help
Actually that's common in the industry. You must realize 3DO was a new platform who was abandoned pretty soon. I've suffered early devkits in the past (and present, lol) and they were from much bigger companies (Nintendo, Sony, etc).That's probably the first time i'm seeing a video game manufacturer providing an incomplete devkit !
At least official developers had debugging tools, I can live with bugs, but give me a debug console at least!
Might would be interesting to check also the MIDI support. PSX used MIDI in most games and if the 3DO SDK does it right, it's even a better idea than streaming AIFF files.A better Sound Player
Music in the Gameblabla's Wrapper does not work at all...
The sound effects does work on the other hand but they need to be really small...
We need a sound player that streams the music from CD and plays sound effects from RAM.
How about forking burgerlib and using just certain parts?A good example might be the Burgerlib, now open-sourced thankfully.
The problem is that it's way too huge so a smaller library would be ideal.
It would be great to have access to the two GPU processors. Or have the SDK sourcecode to bugfix and improve things...Better pixel drawing routines
Faster functions to draw pixels on screen would be nice.
Anyway, this is something I can check.
You can use SaveFile and LoadFile for easy handle of save files:Saving/Loading to NVRAM
A simple example that shows off how to save and load a simple structure
would be nice.
http://hackipedia.org/Platform/3D0/html ... #XREF27076
Lib3DO has a lot of useful wrapper functions:
http://hackipedia.org/Platform/3D0/html ... Ofrst.html
You can't take the sky from me
Re: Things that can be improved
blabla, you can see savegame feature in my 3DO Doom source.
https://github.com/Versusvs/3DO-Doom-extended
That's an old code, but savegame is already in here.
https://github.com/Versusvs/3DO-Doom-extended
That's an old code, but savegame is already in here.
Re: Things that can be improved
I didn't know you could just use LoadFile and SaveFile to save to the NVRAM...
That's good to know !
MIDI is not easy to do on 3DO from what i gathred as you need to manually load the instruments...
I would like just something easy to work with, not the bloated Burgerlib thing...
Also, i must mention but i met a guy called Optimus on Dingoonity and he's working on a 3DO demo with a team !
https://www.youtube.com/watch?v=Oj2LrdX-sMU
https://www.youtube.com/watch?v=o4LrTO62A5o
Damn, that's some fast drawing...
I told him to sign me up if they ever finished their demo.
That's good to know !
I would suggest we look at streaming AIFF/AIFC files first.Might would be interesting to check also the MIDI support. PSX used MIDI in most games and if the 3DO SDK does it right, it's even a better idea than streaming AIFF files.
MIDI is not easy to do on 3DO from what i gathred as you need to manually load the instruments...
Yeah, i'm fine with that too.How about forking burgerlib and using just certain parts?
I would like just something easy to work with, not the bloated Burgerlib thing...
Also, i must mention but i met a guy called Optimus on Dingoonity and he's working on a 3DO demo with a team !
https://www.youtube.com/watch?v=Oj2LrdX-sMU
https://www.youtube.com/watch?v=o4LrTO62A5o
Damn, that's some fast drawing...
I told him to sign me up if they ever finished their demo.
Re: Things that can be improved
Good news, i finally found how to play music and sound !
I ended up simply using burgerlib though...
This code loads the sound file test and then plays it.
PlaySound(0) does nothing so you need to add plus 1 to play the first sound, same for songs.
As for the music, it is looking for Song%insertsongnumberhere% in the Music folder.
PlaySong(1) will play the file Song1, PlaySong(2) will play Song2 and so on.
I think i found a way to save on NVRAM as well.
However, my emulator, 3DOh, doesn't support the NVRAM...
I will test this further later.
Another thing that helped me for my compilation project :
playing another executable.
Make sure to clean up control input, sound effects, music etc... before loading it though or else
you might have some issues !
I ended up simply using burgerlib though...
Code: Select all
Item AllSamples[10]; /* Items to sound samples */
Word AllRates[10];
uint32 MainTask; /* My own task item */
static TagArg SoundRateArgs[] = {
AF_TAG_SAMPLE_RATE,(void*)0, /* Get the sample rate */
TAG_END,0 /* End of the list */
};
OpenAudioFolio();
MainTask = KernelBase->kb_CurrentTask->t.n_Item; /* My task Item */
InitSoundPlayer("system/audio/dsp/varmono8.dsp",0); /* Init memory for the sound player */
InitMusicPlayer("system/audio/dsp/fixedstereosample.dsp"); /* Init memory for the music player */
AllSamples[0] = LoadSample("test.aiff");
GetAudioItemInfo(AllSamples[0],SoundRateArgs);
AllRates[0] = (Word)(((LongWord)SoundRateArgs[0].ta_Arg)/(44100UL*2UL)); /* Get the DSP rate for the sound */
PlaySong(1);
PlaySound(1);
PlaySound(0) does nothing so you need to add plus 1 to play the first sound, same for songs.
As for the music, it is looking for Song%insertsongnumberhere% in the Music folder.
PlaySong(1) will play the file Song1, PlaySong(2) will play Song2 and so on.
I think i found a way to save on NVRAM as well.
However, my emulator, 3DOh, doesn't support the NVRAM...
I will test this further later.
Another thing that helped me for my compilation project :
playing another executable.
Code: Select all
static void RunAProgram(char *ProgramName)
{
Item LogoItem;
LogoItem=LoadProgram(ProgramName);
do
{
Yield();
}
while (LookupItem(LogoItem));
DeleteItem(LogoItem);
}
RunAProgram("mygame");
you might have some issues !
Re: Things that can be improved
Does any of your setups use the vasm assembler?
I believe this assembler supports the ARM processors.
I believe this assembler supports the ARM processors.
http://sun.hasenbraten.de/vasm/Currently the following CPUs are officially supported by vasm (loosely ordered by maturity): •M680x0 family (including M6888x, M68851 and CPU32)
•ColdFire family (all models of V2, V3, V4, V4e)
•PowerPC family (POWER, 40x, 440, 460, 6xx, 7xx, 7xxx, 860, Book-E, e300 and e500)
•Z80 family (Z80, 8080, GBZ80, 64180, RCM2/3/4k)
•6502 family
•Jaguar RISC (GPU and DSP instruction sets)
•ARM (architecture ARMv1 to ARMv4, including THUMB mode)
•80x86 family (IA32 8/16/32 bit, using MIT-syntax)
•C16x/ST10
•6800 family (6800, 6801, 6803, 68HC11)
•QNICE (elegant 16-bit FPGA CPU)
•TR3200 (virtual CPU from 0x10c)
•Raspberry-Pi VideoCore IV
What came after the Jaguar was the PS1 which for all it's greatness, ushered in corporate development and with it the bleached, repetitive, bland titles which for the most part we're still playing today. - David Wightman