#101718 - OOPMan - Thu Sep 07, 2006 5:33 pm
Okay, a while back I posted in the DS Ports thread the idea of doing a port of the Ur-Quan Masters to the DS.
Yesterday I joined the UQM forums and posted a topic on the feasibility of a DS port. I've gotten some useful feedback from in that topic, which can be found here...
I created that topic with two basic scenarios in mind. One option would be to port UQM to the DS as is and get it working in that context. The other option would be to create a data-compatible clone with the aid of the UQM source code that caters specifically for the DS's capabilities.
In a nutshell the issues raised with the idea of doing a vanilla port can be broken down into the following areas:
I'm going to detail my thoughts on these issues and I'd like to hear your ideas on the issues as well...
4mb Memory Limit
Doing a vanilla port of UQM raises the issue of the DS's 4mb memory limit. UQM was developed using the 3DO version of Star Control 2's source code and has been targetted at PC's a bit more powerful than what ran the original SC2. Hence, it's memory requirements are a fair bit higher than might be expected.
I think this problem can be approached from a number of angles. One way too approach things would be to do an audit of the game resources and remove what isn't needed while reduce the memory consumption of everything else as much as possible while maintaing as high a standard of quality as possible that is suitable to the DS's hardware.
Now, considering that SC2 was originally designed for systems running at 320x200, there's probably only a minimal amount that can be done to the graphics. The basic SC2 music comes in the form of tracker created .mod files. Seeing as how we have a tracker application on the DS, I think it's safe to say that using the original PC version music would be do-able.
The 3DO version provided some bonuses in the form of spoken dialog. While it would be nice if we could get this working, it's not essential and would only be a later goal, if indeed it is possible, given the 3DO data...
It would also be a good idea, I think, to leverage the the useful fact that DS homebrew relies on fairly fast solid-state memory solutions. Hence, pulling data in on the fly is probably less of an issue than with a HDD, although that's no reason to get sloppy...
Mildly multi-thread nature of the UQM code
The UQM code has, over time, become somewhat multi-threaded in nature. Apparently this threading isn't strong or very vital and could be unraveled into a single thread if necessary.
Being new to DS coding I'm not too certain how the devKitARM compiler handles threaded code, or whether it even supports it. Seeing as how the multi-threaded components are apparently not vital, they could probably be dumped.
Still, the ignores the fact that UQM was originally coded for a single-processor based system, while the DS is a dual-processor system. Hence, in order to get things running really well it might be neccessary to extensively rework the code into a form more suitable for the DS's processors...
Suitability of SDL DS to the project
UQM on PC has been coded using SDL, which has been ported. The question is, though, just how efficient an implementation of SDL has been done on the DS's hardware? At present the DS version of SDL lacks support for sound and a few other things as well...
My thinking is that if extensive re-working of the UQM code is necessary then it might not be a bad idea to rip out SDL DS entirely and replace it with something more mature, such as PALib (Or one could go a bit more low level and make use of the basic NDS homebrew libraries...)
Limited CPU power
While the original SC2 game was targetted at 386 machines, the UQM code is based on the 3DO code and has been targetted at more recent PCs. Hence, it's CPU requirements are higher than one would expect...
I think that with careful coding and work, this wouldn't be such a problem. CPU intensive elements could be optimised or altered or even removed completely, as long as the gameplay itself is not affected.
Splitting the game load across the DS's two processors on a fashion that takes advantage of their roles would probably also reduce the important of this problem. Of course, that would involve some extensive re-coding of the game, since it wasn't designed with the DS in mind originally...
Screen configuration
As is, UQM's base resolution is 320x240. Although the original PC version ran at 320x200, the 3DO version jumped this up a little.
The basic UQM interface is not inherently supportive of the DS's dual screens, although certain elements such as planetary exploration do lend themselves rather more in the UQM version than in the original PC version (See the UQM wiki for details on the Version differences).
My thinking is that in the long run a port would do best to re-work the interface in such as fashion that it always makes maximum use of the DS's screen space.
During Space Navigation the navigation would occur on the top screen while the touch screen displays HUD data and any other secondary components.
Communications would see all dialog placed on the touch screen while the image display would occur on the upper screen.
Similarly, the basic planetary screen would display the planet on the upper screen while presenting planetary options on the lower screen.
Planetary exploration would occur on then upper screem, with the lower screen containg options and possibly some kind of minimap.
Melee would be handled similarly to planetary exploration, with the lower screen containg HUD info and a minimap of some kind. The upper screen would display the combat itself (If a minimap were used then certain elements of UQM's screen zooming feature could be dumped, as they catered mainly for two people playing on one machine)
My closing comments...
My opinion, having taken a look at the issues raised by posters on the UQM forums, is that doing a vanilla port would not be optimal. I believe that doing a clean clone that remains data compatible with the UQM files and incoporates and the game logic of UQM itself would be a better approach. Whiel this approach does present it's own problems, it would allow use to better make use of the DS's capabilities.
However, I am, as I've said before, new to the DS homebrew scene and hence my opinions and ideas do not have much grounding in DS coding experience. Hence, I'd really really like to hear what you guys think about all this?
Would a vanilla port be best, or should a clone be pursued? What about the issues raised? Neither a port nor a clone can ignore them. What's your take on all this?
Anyway, I hope to get some interesting discussion on this...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
Yesterday I joined the UQM forums and posted a topic on the feasibility of a DS port. I've gotten some useful feedback from in that topic, which can be found here...
I created that topic with two basic scenarios in mind. One option would be to port UQM to the DS as is and get it working in that context. The other option would be to create a data-compatible clone with the aid of the UQM source code that caters specifically for the DS's capabilities.
In a nutshell the issues raised with the idea of doing a vanilla port can be broken down into the following areas:
- 4mb Memory Limit
- Mildly multi-threaded nature of the UQM code
- Suitability of SDL DS to the project
- Limited CPU power
- Screen configuration
I'm going to detail my thoughts on these issues and I'd like to hear your ideas on the issues as well...
4mb Memory Limit
Doing a vanilla port of UQM raises the issue of the DS's 4mb memory limit. UQM was developed using the 3DO version of Star Control 2's source code and has been targetted at PC's a bit more powerful than what ran the original SC2. Hence, it's memory requirements are a fair bit higher than might be expected.
I think this problem can be approached from a number of angles. One way too approach things would be to do an audit of the game resources and remove what isn't needed while reduce the memory consumption of everything else as much as possible while maintaing as high a standard of quality as possible that is suitable to the DS's hardware.
Now, considering that SC2 was originally designed for systems running at 320x200, there's probably only a minimal amount that can be done to the graphics. The basic SC2 music comes in the form of tracker created .mod files. Seeing as how we have a tracker application on the DS, I think it's safe to say that using the original PC version music would be do-able.
The 3DO version provided some bonuses in the form of spoken dialog. While it would be nice if we could get this working, it's not essential and would only be a later goal, if indeed it is possible, given the 3DO data...
It would also be a good idea, I think, to leverage the the useful fact that DS homebrew relies on fairly fast solid-state memory solutions. Hence, pulling data in on the fly is probably less of an issue than with a HDD, although that's no reason to get sloppy...
Mildly multi-thread nature of the UQM code
The UQM code has, over time, become somewhat multi-threaded in nature. Apparently this threading isn't strong or very vital and could be unraveled into a single thread if necessary.
Being new to DS coding I'm not too certain how the devKitARM compiler handles threaded code, or whether it even supports it. Seeing as how the multi-threaded components are apparently not vital, they could probably be dumped.
Still, the ignores the fact that UQM was originally coded for a single-processor based system, while the DS is a dual-processor system. Hence, in order to get things running really well it might be neccessary to extensively rework the code into a form more suitable for the DS's processors...
Suitability of SDL DS to the project
UQM on PC has been coded using SDL, which has been ported. The question is, though, just how efficient an implementation of SDL has been done on the DS's hardware? At present the DS version of SDL lacks support for sound and a few other things as well...
My thinking is that if extensive re-working of the UQM code is necessary then it might not be a bad idea to rip out SDL DS entirely and replace it with something more mature, such as PALib (Or one could go a bit more low level and make use of the basic NDS homebrew libraries...)
Limited CPU power
While the original SC2 game was targetted at 386 machines, the UQM code is based on the 3DO code and has been targetted at more recent PCs. Hence, it's CPU requirements are higher than one would expect...
I think that with careful coding and work, this wouldn't be such a problem. CPU intensive elements could be optimised or altered or even removed completely, as long as the gameplay itself is not affected.
Splitting the game load across the DS's two processors on a fashion that takes advantage of their roles would probably also reduce the important of this problem. Of course, that would involve some extensive re-coding of the game, since it wasn't designed with the DS in mind originally...
Screen configuration
As is, UQM's base resolution is 320x240. Although the original PC version ran at 320x200, the 3DO version jumped this up a little.
The basic UQM interface is not inherently supportive of the DS's dual screens, although certain elements such as planetary exploration do lend themselves rather more in the UQM version than in the original PC version (See the UQM wiki for details on the Version differences).
My thinking is that in the long run a port would do best to re-work the interface in such as fashion that it always makes maximum use of the DS's screen space.
During Space Navigation the navigation would occur on the top screen while the touch screen displays HUD data and any other secondary components.
Communications would see all dialog placed on the touch screen while the image display would occur on the upper screen.
Similarly, the basic planetary screen would display the planet on the upper screen while presenting planetary options on the lower screen.
Planetary exploration would occur on then upper screem, with the lower screen containg options and possibly some kind of minimap.
Melee would be handled similarly to planetary exploration, with the lower screen containg HUD info and a minimap of some kind. The upper screen would display the combat itself (If a minimap were used then certain elements of UQM's screen zooming feature could be dumped, as they catered mainly for two people playing on one machine)
My closing comments...
My opinion, having taken a look at the issues raised by posters on the UQM forums, is that doing a vanilla port would not be optimal. I believe that doing a clean clone that remains data compatible with the UQM files and incoporates and the game logic of UQM itself would be a better approach. Whiel this approach does present it's own problems, it would allow use to better make use of the DS's capabilities.
However, I am, as I've said before, new to the DS homebrew scene and hence my opinions and ideas do not have much grounding in DS coding experience. Hence, I'd really really like to hear what you guys think about all this?
Would a vanilla port be best, or should a clone be pursued? What about the issues raised? Neither a port nor a clone can ignore them. What's your take on all this?
Anyway, I hope to get some interesting discussion on this...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...