Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

grahamr

Portability in a portable world

This topic is 5156 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Say you were writing a game for portable machines, and the platforms you are targetting are N-Gage, GBA, & PDA. All differing machines, but with one common feature - portable. Now the game you are writing is just a simple puzzler, the engine logic and functions are all the same, but somewhere along the line you have to write system specific code. My original plan (and how it currently stands) was to write everything as a subsystem of CEngine and have CRenderer, CInput, CSound, etc. etc. as a has-a relationship. Problem is you start having to place #ifdefs in the headers, and the code becomes a maintainablitity nightmare. So I currently thinking around this. My first solution involves abstracting all the classes that require specifics from a base class for that type and then have a #define PLATFORM that replaces all occurances of PLATFORM with the correct type and this will give the correct directory for the specifics. The other is to create an CSystemSpecific class and that will have all the system specific stuff contained within it and pass that to the engine class. Even though this will give the cleanest code it doesn''t appear very elegant. Any ideas?

Share this post


Link to post
Share on other sites
Advertisement
You are using a run-time solution for a compile-time problem.

The cross-platform layer should be below your object framework. You should have a portable API, like SDL.

Share this post


Link to post
Share on other sites
> The cross-platform layer should be below your object framework.

So I should go with my second idea? One big class with lots of has-a relationships or have SetRenderer(), SetSound(), etc. in the Engine class?

> You should have a portable API, like SDL.

I prefer to write my own - that way I know why things work (or don''t). Also it is better for learning. I once took over code that accessed a DVCam machine. I was supposed to add support for an Oracle database. In the end I rewrote the dvcam accessing as well as the intermediate functionality as well as the database interface. I could of simply bolted the database on but now the code is more reliable (the packets from the dvcam are parsed properly and acted upon as such) and shouldn''t need to be touched for another few years.

Share this post


Link to post
Share on other sites
quote:
Original post by grahamr
I prefer to write my own - that way I know why things work (or don''t). Also it is better for learning. I once took over code that accessed a DVCam machine. I was supposed to add support for an Oracle database. In the end I rewrote the dvcam accessing as well as the intermediate functionality as well as the database interface. I could of simply bolted the database on but now the code is more reliable (the packets from the dvcam are parsed properly and acted upon as such) and shouldn''t need to be touched for another few years.
LOL!

Do you know what happens when existing, working code gets thrown out in favor of a "fresh, clean rewrite"? Knowledge is lost. Yes, all the knowledge accrued in the exist solution in the form of bugfixes, obscure tidbits of information that the new code has to stumble over and grow painfully from. Reimplementation can be a good thing, but only when warranted, and properly auditing the existing solution is a good idea to eke out those nuggets of experience.

In any case, MKH said "like SDL", not "use SDL".

Share this post


Link to post
Share on other sites
In this case, though, I think he will have to write his own code to provide uniform access to three very different API's. Here is the way I would do it: have a class MyEngine with one interface and different implementations. Write one MyEngine.h for all of them and write indivual MyEngine_GBA.cpp, MyEngine_nGage.cpp, and MyEngine_Palm.cpp files with the actual code. That way the logic doesn't have to know about which system it's running on, just compile thw right one with each build. The three implementations might just be wrappers for an existing API.

There might be a better solution; I'm not a guru or anything.

[edited by - nagromo on April 12, 2004 11:35:36 PM]

Share this post


Link to post
Share on other sites
Yes, I recommend doing it like nagromo says too. I would add a forth cpp file, MyEngine_common.cpp, for common functionality though. Write as much code as possible there, but if you start using too many #ifdef''s, move it to the platform cpp file.

Also use small functions, instead of huge ones that does a lot of things. That makes it a lot easier to share the same function for all platforms.

If the actual class interface has to be different between the platforms, you should rethink your design. If you don''t find a good way, then at least make the differences as few as possible, and only in lowlevel classes. The actual game logic should not be dependent on this at all.

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Do you know what happens when existing, working code gets thrown out in favor of a "fresh, clean rewrite"? Knowledge is lost. Yes, all the knowledge accrued in the exist solution in the form of bugfixes, obscure tidbits of information that the new code has to stumble over and grow painfully from. Reimplementation can be a good thing, but only when warranted, and properly auditing the existing solution is a good idea to eke out those nuggets of experience.

In any case, MKH said "like SDL", not "use SDL".


That existing, working code lost clips (i.e.: three runs would produce three different results, start times, and number of clips found). It has had bits bolted on to it by three different authors and was last touched in 1998 (to add a treeview to it of all things). I was supposed to simply bolt another piece of code to the side and leave it at that. Now it always returns the correct number of clips, though sometimes there are slight variations in either the start or end times codes by ~1 frame.

Also I now know about the Sony 9 pin Remote Protocol:-)

Okay, I will start implementing the SetRenderer(), SetSound() and see where that takes me...

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
Do you know what happens when existing, working code gets thrown out in favor of a "fresh, clean rewrite"? Knowledge is lost. Yes, all the knowledge accrued in the exist solution in the form of bugfixes, obscure tidbits of information that the new code has to stumble over and grow painfully from. Reimplementation can be a good thing, but only when warranted, and properly auditing the existing solution is a good idea to eke out those nuggets of experience.


Knuth more or less says that a complete rewrite is one of the best things that can happen to a software project. Spolsky more or less says that a complete rewrite is never necessary and is a waste of time. Considering that Knuth has made significant contributions to the field of computer science, and Spolsky has made significant amounts of wind, I''ll side with Knuth on this one.

However I think it''s fair to say that as the size of both software and programming teams increases, Knuth''s idea becomes less and less practical. I think it''s safe to assume that the OP''s software is not large enough to side with Spolsky.

Share this post


Link to post
Share on other sites
It can be a good idea to write a prototype and throw it away and start again. But only because you will have learned something in the process.

Throwing away something that you can't be bothered to learn how to use is just laziness.

You can't always throw away a project, especially if it is really large.

These are often difficult decisions to make though and I wouldn't like to say 'You should do this or that'.

edit: On the whole I am for refactoring (which is working with existing code to improve it and make it better design and more flexible to your needs), and I'm for test first programming which often leads to throwing stuff away (at least for me it does!), but again that's part of the process and not the starting point.

[edited by - petewood on April 13, 2004 11:43:07 AM]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!