This is a forum for discussing the feasibility of getting emulators, games, or other applications that have had their source released ported to the Dreamcast. Please read the Porting FAQ before starting a topic in this forum!
Hi, I'm not exactly new to this site. I've actually have been coming here for the past 2 years. However, today I've decided to join the forums Now to my question, I wanted to know would any of the developers here have any interest in helping to get OpenMugen to work for the dreamcast. I have been over at OpenMugens website and someone there had hinted that the engine might not be compatible for dreamcast due to it's technical limitations. However, I believe there could be an optimized version of this if some of the features were left out. Just keep the regular features of the original mugen engine if this is possible. I've been to dreamcast-scene to put the word out there so I hope to get a response from them as well as you guys. It would really help. Thanks
I was actually going to work with xirtamon on a mugen engine, but I lost my code in a hdd crash.
The limitations of Mugen on DC are mainly ram, since some characters can be HUGE, there would have to be a 4 mb limit on characters in 2p or 1p mode, and when there are 4 players, then it would have to be limited to 2, since there is need for overhead. Otherwise, I dont see too many problems with it.
I havent been to mugen in a LONG time, I oughta see whats cookin.
Dark Savant0 wrote:I was actually going to work with xirtamon on a mugen engine, but I lost my code in a hdd crash.
The limitations of Mugen on DC are mainly ram, since some characters can be HUGE, there would have to be a 4 mb limit on characters in 2p or 1p mode, and when there are 4 players, then it would have to be limited to 2, since there is need for overhead. Otherwise, I dont see too many problems with it.
I havent been to mugen in a LONG time, I oughta see whats cookin.
Ya the problem is really that either you'd have to really work every individual mugen game itself after the engine been ported to optimally run on DC or face a massively slowed down mess of a game. You might be thinking that since the DC can handle Soul Calibur or DOA2 that this is an easy feat, but with 2d animated games you cannot have a rubrick to work off of, while those games have wireframes and simply have textures over them which change with the movement, in 2d fighting game for every move you have I image at least 30 frames of animation for a second of movement, which can be extremely ram exhausting.
Fyifa Is In Love With Drajjia?
Drajjia is so drugs with Fyifa?
Even a couple screenpacks are too big to allow for additionall players. And forget bg music, unless its very small (like an spc or something).
I believe the max on a screenpack would be like 2 mb, small less than 200 kb music files, stages max at 1 mb, with the actual engine using 2-4 mb, leaving 9 mb for characters. Plus not to mention the fact that openmugen in itself is not that advanced(last I checked) so with every new release there would be a new base. Perhaps when Openmugen is complete, maybe someone will do it. But it is not, so too bad. I imagine that the input file is slowing them down, it took me about a month to figure it out.
Like I said before, its ram that is limiting us. Go see if the xboxers are interested.
If ram is limiting us, how do commercial 2d fighters for the DC handle the problem, games like Marvel vs. Capcom 2 and Street Fighter 3? I'm not trying to challenge anyone's opinion here, it's just a curious programming question
They use the Dreamcast's 3D hardware (which has about 5MB of memory that's usable for textures), they could use texture compression on backgrounds, they use low-colour paletted images (4- and 8-bit images), they use fragments of sprites and backgrounds rather than the large image files Mugen uses, and they're actually written for a games console, so they have memory efficiency in mind. PC games almost never do any of that, especially 2D games.
Basically, creating a 2D games for a games console with limited RAM and a 3D accelerator is completely different than creating 2D games for a PC with virtually unlimited RAM and 2D graphics hardware (which is what Mugen was designed for).
A good example - Beats of Rage. That had some probems with running out of memory, because it actually used two copies of each sprite - one facing each direction. That's just wasteful - none of the sprites had different animations depending on what direction they were facing, so the copies were just flipped copies of each other. Console games never do that - they just flip the sprites as they draw them. So the guy who ported it made it flip the sprites as it drew them, and removed the code to load the other set of animations. Cut the memory usage almost in half. OK, so it was no longer possible to use different animations depending on which direction the character was facing. Had the game (and graphics) been designed with RAM limitations in mind, there wouldn't have been a problem.
Another good example - As far as I'm aware, Mugen uses true-colour (actually, 16-bit colour) for everything - backgrounds, sprites, video output, everything. The images take up two bytes of memory per pixel, and can not use colour palettes. That means that you need a separate copy of all the animations just to change the colour of the character. So if you have three colours for a character, you need basically the same data duplicated three times. If you used 8-bit images, with a single 256 colour palette for each character, you could get around that quite easily. You'd only be able to use 256 colours in a sprite, but that's not much of a limitation really. Not only would the images be half the size, but you'd be able to add new colours by adding 768 bytes for a new colour palette (or on the Dreamcast, 512 bytes if you store the palettes in the Dreamcast's native format). You can use the same technique for backgrounds as well, and you can mix 4-bit (16 colour) and 8-bit (256 colour) images quite freely. Commercial 2D fighters do this extensively, and their artists are good at drawing images with very few colours. Bear in mind that, in the SNES days, the maximum number of colours you could put in a single sprite was only 16, and even the NeoGeo couldn't do more than 256 colours per sprite. Although you can always glue multiple sprites (with different colour palettes) together to form a larger sprite with two colour palettes.
I think for a modifiable fighting game to be made, BOR would have to be edited to support some additions and some subtractions. That is the best way.
Heck, I would look into it, except coding interests me no more and I dont know where to get the source.
But I do believe BOR is a hop, skip, and a jump away. Perhaps the next version (that other Senile project) will be better for the modification, I dunno.
Dopey Dark Savant0 wrote:I think for a modifiable fighting game to be made, BOR would have to be edited to support some additions and some subtractions. That is the best way.
I see no mention of weapons, although it seems VERY interesting. Some of those features could be used in a "mugen" type engine. However, buttons would have to be remapped and such, in order to get better playability. The characters would also have to be cleared from memory, something that I have not seen confirmation of happening. That way several "stages" could be played.
As far as the "paks" go, do they save in memory and such? It seems to me that the whole pack has to be loaded, while one could just as easily open some simple ini and text files to see what needs to be loaded from within the subfolders for whatever. I don't see a point to it except smaller loading time, although I may be wrong. Can anyone clear this up for me.
I am getting interested in a "mugen" type engine for the DC every day. I just might go back to programming for this. Unless this someone else is doing it. But I do think it might be feasible.
BoR loads only those files in RAM that are needed, e.g. the txt files that do contain info about your game's structure, the playable characters etc.
Scenes, music and such are precached but don't stay in RAM (so in theory you could have a PAK filling a whole CDR with music and cutscenes only).
Levels, sound effects and enemy characters are loaded when needed and remained in the RAM even when not needed anymore - thus you could play up to lets say stage 4 but then the game froze at the loading stage of stage 5 (on DC). If I understood correctly Roel's memory fix (now part of OpenBoR) frees the RAM after each stage and thus would allow much huger sprites and stages.
I ask this question because if it will be like a "mugen" type engine, I dont think too many people will like repacking their "games" everytime a new character they want is made. That way all you have to do is add the first cfg file of a character to the file that loads characters.
What is the resolution of OpenBOR? Standard Dreamcast resolution?
What is OpenBOR compiled with?
Is there any way to increase the number of moves that each character can have, or is that an engine limit? Because if there is a way to increase move amount, then it would allow for a better fighting engine. And are the moves configurable by button press? For example, holding "A" for 3 seconds, and pressing down, back, forward, and then releasing "A" in order to make a move?
I am sorry for hijacking this thread. It just brings back memories.
Now to my question, I wanted to know would any of the developers here have any interest in helping to get OpenMugen to work for the dreamcast. I have been over at OpenMugens website and someone there had hinted that the engine might not be compatible for dreamcast due to it's technical limitations. However, I believe there could be an optimized version of this if some of the features were left out. Just keep the regular features of the original mugen engine if this is possible. I've been to dreamcast-scene to put the word out there so I hope to get a response from them as well as you guys. It would really help. Thanks 
