 |
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|
||
|
|
||
|
|
||
|
|
|
|
|
|||||||||||||||||
Add Forum to Favorites | Send Topic To a Friend | View Forum FAQ | Track this topic Page: 1 2 3 4 5 6 7 8 9 10 »» |
Last Thread Next Thread |
| Enginuity, Part IV |
|
 |
Austrian Coder Member since: 4/6/2002 From: Austria |
|||
 Posted - 8/2/2003 5:45:33 AM |
||||
| Great article, like the others! The tasksystem is cool, i have implantated in my engine. I would change this: void CSoundTask::Update() { FSOUND_Update(); //This updates the 3d sound engine and DMA engine (only on //some platforms), and should be called once a game frame. //This function will also update the software mixer if you //have selected FSOUND_OUTPUT_NOSOUND_NONREALTIME as your //output mode. } Greets, Christian |
||||
|
||||
|
Pipo DeClown Member since: 2/16/2002 From: Amsterdam, Netherlands |
|||
|
Posted - 8/2/2003 5:46:09 AM |
||||
Wow you're quick, it just got online  .lick |
||||
|
||||
|
Austrian Coder Member since: 4/6/2002 From: Austria |
|||
|
Posted - 8/2/2003 5:48:13 AM |
||||
| I am a fast reader *g* |
||||
|
||||
|
Taharez GDNet+ Member since: 6/18/2000 From: Stockholm, Sweden |
|||
 Posted - 8/2/2003 7:09:01 AM |
||||
| About time :D Nice work, and keep 'em coming! |
||||
|
||||
|
Leffe Member since: 3/3/2003 |
|||
|
Posted - 8/2/2003 7:17:51 AM |
||||
Putting the priority in the constructor of the tasks might be a good idea  |
||||
|
||||
|
Helius Member since: 3/7/2000 From: Madrid, Spain |
|||
|
Posted - 8/2/2003 7:41:02 AM |
||||
| good work! but, where is "game.h"??, I think some code is missing... don't you? |
||||
|
||||
|
ggs Member since: 1/2/2000 |
|||
 Posted - 8/2/2003 8:36:37 AM |
||||
| Good work. I'll hammer out some pascal translations when I get some free time sometime this week. |
||||
|
||||
|
Per Ohlsson Member since: 7/21/2003 |
|||
|
Posted - 8/2/2003 8:53:58 AM |
||||
| It definatly seems like some files are missing from the source code. |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 10:38:15 AM |
||||
| I am in the middle of porting the engine to OSX and my cross platform build system (Jam/mingw on osx with custom rules), but so far it seems that some simple editing of engine.h fixes many of the issues in building. It seems that engine.h belongs to a much more advanced version of the engine than what we are seeing. Obviously other work has been done already on textures, networking, sound, probably scene graph, etc, etc.. I'll post more if I run into any other issues in building. Jeff Jeff Thompson CTO, CodeTek Studios, Inc. http://www.codetek.com/ |
||||
|
||||
 |
superpig GDNet Technical Lead Member since: 5/26/2001 From: Oxford, United Kingdom |
|||
|
Posted - 8/2/2003 11:05:59 AM |
||||
Austrian Coder: good work, you beat pan narrans  I didn't know about the FSOUND_Update() call - I guess it's not required on Win32 and thus not in the SDK. Still, it'll be useful if I port the engine to GBA like I've been thinking (FMOD supports GBA, right?). Leffe: you mean a 'default priority?' I guess you can, but I'd suggest that instead you initialise to a value of -1 (or some other priority value that will never be used), and then assert in AddTask() if the priority hasn't be set. About the source code: oops. Yes, the engine is a fair way forward from here (dynamic textures, a mildly buggy skeletal animation system, interpolators/triggers, etc etc), and I must have put the source together in a bit of a hurry, so I didn't remove all references to the current bits of the engine. I'll fix the source and send Dave a new version. Superpig - saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery. Enginuity1 | Enginuity2 | Enginuity3 |
||||
|
||||
|
LoreKeeper Member since: 6/11/2000 From: Stellenbosch, South Africa |
|||
|
Posted - 8/2/2003 11:10:15 AM |
||||
| I'd like to know why you tried to avoid having multiple inheritance (CSingleton) in the Timer and Input classes. |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 11:17:21 AM |
||||
| Noticed that the fix to the operator= code was not put into this new version. I think it was discussed in the 3rd articles forums. No biggie. For those of you using gcc, you need to modify mmanager.h on about line 43 (modify the following to inlines to be: inline CMMPointer { if(obj)obj->Release(); obj=p.obj; if(obj)obj->AddRef(); return (*this); } inline CMMPointer { if(obj)obj->Release(); obj=o; if(obj)obj->AddRef(); return (*this); } Also, in Settings.cpp there is another gcc issue. RegisterVariable is defined to take references to its two arguments, however in Settings.cpp the SETTING macro tries to pass temporaries by reference to this function. gcc won't let you do this so the compile fails. The quick fix is to just change Register variable to the following: void RegisterVariable(std::string name, CMMPointer<baseDator> var); otherwise you have to dump the SETTING macro and not use temporaries. Don't know why gcc has this limitation, but it's there.  I'm going to look into adding message box support into Log.cpp for OSX in a moment and figure out the few remaining errors in mmanager.cpp, VideoUpdate.cpp, and main.cpp. I'll post those as well and then we'll have source compatability with osx, and likely better with other unixie os's. Cheers, Jeff |
||||
|
||||
|
deepdene Member since: 3/12/2001 From: Australia |
|||
|
Posted - 8/2/2003 11:25:48 AM |
||||
| Probably overused the old singleton there a bit at times Other than that the structure of the code seems quite solid. I like the idea of task management and I'm thinking of adapting the idea to my own games. Thinking of perhaps making the task management thread safe using SDL's threading routines (that way it's multiplatform). Since that'd be the next natural extension of it. |
||||
|
||||
|
superpig GDNet Technical Lead Member since: 5/26/2001 From: Oxford, United Kingdom |
|||
|
Posted - 8/2/2003 11:56:50 AM |
||||
| LoreKeeper: it wasn't so much a desire to avoid multiple inheritance (as both ITask and Singleton shouldn't have problems with it); it was just more of a conceptual feeling that tasks shoudln't be singletons. Maybe I'm just being silly about it. jwthomp: oops. I think there are about 3 copies of the code knocking about on my system, so I may well have put the changes into one set and not another. deepdene: Heh. I don't much like SDL's implementation of threading (a few things seem to be missing, like a yield() type function. However, I think they're unavoiable in the networking system, so they'll be used eventually. Superpig - saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery. Enginuity1 | Enginuity2 | Enginuity3 |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 12:05:59 PM |
||||
| superpig: no worries, just wanted to alert you to the fact. For anyone else having issues: I've: - commented out the texture code in VideoUpdate.cpp as this is not implemented in our version. - Wrote my own game.h #include "engine.h" class CApplication : public Singleton { private: CGlobalTimer *globalTimer; CVideoUpdate *videoTask; CInputTask *inputTask; CSoundTask *soundTask; public: void Run(int argc, char *argv[]); }; - Commented out InitRandomNumbers in main.cpp since this is not implemented anywhere. - Wrote a portable_qAbs routine for main.cpp since qAbs is not implemented on osx. inline float portable_qAbs(float value) { return value < 0 ? -value : value; } - Wrote a portable_min routine for mmanager.cpp since it is not implemented in osx inline int portable_min(int left, int right) { return left < right ? left : right; } - Found that Kernel has the same temporary reference problem with AddTask as it is called with temporaries. I've decided to just put these methods back to being reference arguments and get rid of the temporaries.. superpig: If you ever want someone to test your stuff out on osx before "shipping" please feel free to let me know. I'm happy to help. I can be reached on AIM as Mythrandir1024 or via email at jwthomp@codetek.com I'm going to work on getting fmod to work properly. It seems to be causing some problems. (osx platform specific) Cheers! Jeff |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 12:18:52 PM |
||||
| Ok, I have it all running now on OSX. One thing to make sure is to copy the strings file into the current folder. The only problem I am seeing is that the graphics are really messed up. This will take some thinking. It's clear from the screen that the game logic is working, but the graphics are all sheared all over the screen. I'm sure its probably something trivial. I'll report on what I find. Just out of curiosity, is anyone else building on OSX? You may eventually be interested in the work I am doing in my spare time. I have a Jam based build environment with the standard osx gcc tools, as well as mingw compiled ones. I have written my own jam rules that lets me build to osx or windows like so: jam -s arch=osx or jam -s arch=windows. I added rules that build SDL based applications so you don't have to even touch the SDL main stuff or worry about linking in the right libraries. I'm getting the ODE physics package built in as a standard library for building, and will be including the engine from this series in it as well. This essentially becomes a nice build environment for osx/windows games based on SDL. Once I get things a little cleaner (packages and automated source builds of the whole thing so I can distribute source rather than large binaries), I'll put it up for public consumption. Has anyone else gotten the engine built and running on windows? Do you see graphics problems, or am I encountering a platform issue or something bad I've done ?Cheers! Jeff |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 1:07:58 PM |
||||
| Fixed the graphics problem. It had to do with running in full screen at 800x600. I'm running on my iBook so I'll try it on another system to see what happens. Now that I am using references I had to do the following: In main I changed the AddTask code to look like: (showing one example, easy to duplicate to the others): globalTimer=new CGlobalTimer(); globalTimer->priority=10; CMMPointer CKernel::GetSingleton().AddTask(t1); In Settings.cpp I had to change the SETTING macro to: #define SETTING(type, target, var, name) target=new Dator Now its time to verify that I can cross compile this to windows properly in my build environment. Jeff |
||||
|
||||
|
denJeebus Member since: 3/24/2003 |
|||
|
Posted - 8/2/2003 2:05:39 PM |
||||
| I'm VERY interested in your working OSX version. I've had an iBook for a few months now but I haven't given too much time to development, and I'd love to compare this Engine code with some working OSX stuff. I got a version based on the 3rd tutorial to compile on OSX, but when I tried to USE it things went pretty badly (for me it was in the Dator stuff). For instance, this code works on Windows: // a variable of almost any type will do int l_iNumber; l_iNumber = 10; // create a dator that is bound to it CMMPointer< CDator l_Dator = new CDator // assign a value to the Dator (*l_Dator)=std::string("37"); // the value of the int is now 37 But I got all kinds of errors trying to compile that on OSX. I'll post those as soon as I get back to the system, but it might be easier for me to learn from somebody who's used the system before (and thankfully somebody who isn't using Obj-C). I think the problem was with how I'd defined the = operator, but I'm almost positive that I'd done it the way that was listed in the forum. Anyway, drop me a mail at jeebus at cfl dot rr dor com, if you please! |
||||
|
||||
|
pan narrans Staff Member since: 6/4/2002 From: Leeds, United Kingdom |
|||
|
Posted - 8/2/2003 2:20:16 PM |
||||
quote: Figured I was starting to look like a fanboy pan narrans | My Website | Study + Hard Work + Loud Profanity = Good Code |
||||
|
||||
|
jwthomp Member since: 3/6/2002 From: Champaign, IL, United States |
|||
|
Posted - 8/2/2003 2:43:27 PM |
||||
| HELP: I've got everything building cross platform and it all works. BUT, I'm having a very strange problem with SDL on Windows. When I launch the application the window frame appears immediately (SDL creates the window fast). However, after this it take a long time for the opengl context to be fully initialized and drawn so I start to see the game. The problem is that the game was already running in the background (I just didn't see any drawing). I modified the source so the game doesn't quit when the ball goes off screen. So what happens is that the ball is gone by the time I start seeing graphics. I don't mind the slow startup time of opengl so much, as I do the fact that I don't know how to wait for it to be ready. I don't want to start running through a games logic before the video system is "really" ready. Does this ring any bells with anyone? Any advice or thoughts? Thanks! Jeff denJeebus: Good to see another one of us! Check out my companies VirtualDesktop product for Mac OS X (it rocks) at www.codetek.com/virtual/ We'll definitely have to connect when I get my build system further along. Also, I should mention it currently only runs on Panther as I've been unable to get mingw to compile on Jaguar so far.. |
||||
|
||||
|
Naku Member since: 6/25/2001 From: United Kingdom |
|||
|
Posted - 8/2/2003 4:42:59 PM |
||||
| Umm, I got a bit of a problem here. When AddTask is called like: AddTask(CMMPointer one of the = operators is used. But when the operator function returns (*this) the CMMPointer(const CMMPointer [edited by - Naku on August 2, 2003 7:01:22 PM] |
||||
|
||||
|
FroZtY Member since: 8/2/2003 From: Netherlands |
|||
|
Posted - 8/2/2003 5:18:19 PM |
||||
| Hi! I really like the articles. However, there appears to be a little bug in the garbage collector. The code used in the source of part 4 looks like this:
while(deadObjects)
{
IMMObject *nObj=deadObjects->nextObject;
delete deadObjects;
deadObjects=nObj;
}
however, if the last object of the deadObjects list (i.e. deadObjects->nextObject == NULL) actually frees another object when it is destroyed, nObj will still remain NULL, even though there are some other objects in the deadObjects list. Then during the deadObjects = nObj call, the list will be set to NULL and all the objects that should be removed will be lost in memory limbo. I solved this by using the following code:
while (deadObjects) {
iMMObject *obj = deadObjects;
deadObjects = deadObjects->nextObject;
delete obj;
}
If the deadObjects to be removed is the last in the list, it will set deadObjects to NULL before deleting the object, so that any objects added after the destruction of the object will correctly be added to the deadObjects list. Hope this helps. Greetings! (And please excuse my poor English) |
||||
|
||||
|
Seriema Member since: 6/15/2001 From: Stockholm, Sweden |
|||
|
Posted - 8/2/2003 7:25:03 PM |
||||
| YEEY the fourth part was finally released! Damn... waited more for this then T3 "No lies of sugar can sweeten the sournes of reality" }+TITANIUM+{ A.K.A. DXnewbie[onMIRC] |
||||
|
||||
|
superpig GDNet Technical Lead Member since: 5/26/2001 From: Oxford, United Kingdom |
|||
|
Posted - 8/2/2003 7:48:23 PM |
||||
| jwthomp: weird. I've built SDL apps (albeit non-Enginuity) on OSX before, and they've never had that problem. Assuming that you've got the most recent version of SDL and your video drivers (they can be updated on Mac, right?), you could try the relatively hacky workaround of simply delaying your game's start. Just add a 'delayStart' task which adds CGlobalTimer::dT to an internal count each frame, and then it can resume (or simply addtask) the other game tasks once that counter reaches a certain value. I agree though, it's less-than-desired behaviour on SDL's part - perhaps someone on the SDL list would know what's going on. denJeebus: the key difference between Windows and OSX is usually that you use GCC to compile for OSX, and MSVC to compile for Windows; I use MSVC, and there are a number of things which MSVC lets go (like not giving the = operator a return type) which GCC doesn't (and, I'm told, shouldn't, because the language asks for it). Unless you were using MSVC on windows, I suspect that may be your problem. Naku: I think that might be the 'temporary objects' bug some people mentioned earlier. Perhaps their fix - creating a named CMMPointer object on the stack, and passing it in - would help? FroZtY: ahh, good point. I think I spotted it before, but ignored it (because 99% of the time the object will just be collected by the next loop). However, that remaining 1% of the time is of course in the CollectGarbage call made by CollectRemainingObjects, at the end of the app - after which there *is* no next loop. Superpig - saving pigs from untimely fates, and when he's not doing that, runs The Binary Refinery. Enginuity1 | Enginuity2 | Enginuity3 |
||||
|
||||
|
Page: 1 2 3 4 5 6 7 8 9 10 »» All times are ET (US) |
Last Thread Next Thread |
|
