Reality Factory

Then don't make the first big mistake again and build it on top of another engine.

I don't see any mistake by using an existing engine to build Rf on top. If it has all the features you need it would be a waste of time to build your own engine IMHO.

Sorry AndyCR, this isn't pickels. Just an old user coming back around lately. But about the building on top of another engine... Genesis is what makes people talk about an RF2 in the first place. Nuff said.

But about the building on top of another engine... Genesis is what makes people talk about an RF2 in the first place. Nuff said.

If you would build your own engine then it wouldn't be outdated seven years from now???

thats what im wondering, after thinking about it, why would having to (perhaps) update an engine after 7 years and simply write some code to pass the features on to the rf user in the mean time be harder than having to worry about writing both an engine and a gcs at the same time? i can see your point from the flexibility side, but i just dont get it.

sorry for any innacuracies in my last post, it was about 6:45AM

well if you want to get up to at quitck try building a shell arround a quake engine! Look at quake 2 evolved...doom 3 quality with the q2 engine! and its gpl'ed. I have moved from rf to q2e and i have no codeing abilitys. I have changed the ui...added my own levels and models and made my own game. My game has normal and specular mapping. Md3 suppord (soon to be md5) soon to have q3 map support. per pixel lighting. doom 3 mtr file support. Reflection refraction and many greeat goodies. If you were to take the now opensource radiant code you could use q2e an make a program just like world editor except more powerful. Forget genesis...its outdated...you want comercial quality even better than ogre (except in terrein capibilitys) go to q2e. It is constantly updating and can look just like q4. I know...i have personally done it with no coding experence!!!

here are some pics

nice shots! the qeradiant thing sounds enticing, remaking rfeditpro is something im kind of dreading a bit... i might use it, if it werent for the fact that i can get much better than doom3 quality graphics with what im using to build rf2 - alot of things are one generation above what d3 can do; d3 = normal mapping, rf2 = parallax mapping, and so on.

good find though!

the problem is not really that genesis has now become outdated . (Even though i think the new shadow stuff brings it up to par with alot of engines.) Its that Genesis itself is not easy to update. If RF2 had entirely its own code base, it can be designed to be upgraded around the features of RF. Using another engine as the base, a person would have to rely on that being upgraded and the methods used to make those upgrades. Also, why go through the trouble of modifying to sets of code instead of one, to make these upgrades? Using another engine as a base is just a bad move. RF as an example, has shown this. But who cares anyway. I just got picky after testing the new BV demos. Just saying, that's the way I would do it. (If I was a programmer.)

i see what you mean. however, irrlicht and genesis are different animals; genesis, from what i understand, was released in version 1.(3 i think it was?) and then dropped like a stone, never to be updated again (officially). irrlicht is constantly being updated, and with the recent opening of the development process and addition of new team members will only continue to do so.

picture this:

RF2 is completed, and people are using it. Irrlicht comes out with version 0.18, which adds support for displacement mapping. Without having to touch a single line of engine code, i just download the new version of Irrlicht, overwrite the old version of irrlicht, do a quick recompile of rf2 to make sure nothing broke compatibility, then can quickly, often within 4 days, pass the new feature of irrlicht on to rf2 users, because i dont need to have anybody do the engine. otherwise, something like displacement mapping would take... up to two weeks or more to deliver to the user, because i would have to code it into the engine, THEN tell rf2 how to use it.

i think the idea of building an RF 2 on top of an existing engine is definitely a good idea - most 'game engines' are anything but, and are often simply a renderer with some extra features and/or wrappers for sound, networking etc. most barely include a gameshell, which is what RF's strong point is, even to this day.

there are three main factors to consider when deciding what engine you'd want to build something on:

1) the license

2) community activity

3) platform/ compiler support

-----------
License
-----------
- this should be the number one thing that you consider when taking a look at other engines.

take a look at http://www.opensource.org/licenses/index.php for details on the various open source licenses that are available.

depending on what the community's goal is with creating an RF2, the license that the underlying graphics engine uses can be a make or break factor.

I would recommend staying far away from anything GPL licensed. while appealing to open-source advocates, the GPL is basically death to anyone looking to create commercial (ie publishable) games using the engine. I am assuming that an RF 2 would want to be available to people looking to actually publish their own titles, and using the GPL basically will scare any publisher away. using an open-source engine period is scary enough for a publisher, but GPL basically writes off any large publisher, period.

LGPL on the other hand has alot of the benefits of the GPL while leaves the door open for commercial applications - I believe this is what OGRE and other similar graphics engines use, and is definitely alot more 'usable' from the business standpoint.

-----------
Community activity
-----------

this has been said, but choosing an engine that won't be going away any time soon is a big factor, both in choosing an open source engine period, but also in making sure that any RF 2 project doesn't suffer from the 'genesis factor', in becoming obsolete in the near future.

-----------
Platform / Compiler Support
-----------

I would be very careful about any engine that uses anything microsoft-specific. Even using a 'DLL' based plugin system basically rules out console development for the most part, as DLL's are very windows-specific. While some OS do support dynamic linking, they handle them differently than windows, and many consoles do not support dynamic linking of code at all (alot don't even have a file system at all, everything needs to be in your own archive/pack format).

An engine that supports numerous platforms also intrinsically means that the code is written in a more standardized way, it's amazing what simply porting your code from one compiler to another can do to the quality of the code.

Don't get hooked on using one specific compiler, test the codebase with numerous compilers often, this will help you in the long run.

otherwise, i look forward to seeing what the community can come up with ;}

excellent advice from someone who has been through the uncomfortable legal issues - thanks!

as for the testing on multiple compilers bit - from my blog:

AndyCR's Blog wrote:... Though my main development environment is Visual C++ 2005 Express Edition, I will be periodically testing for compatibility with many popular compilers - MinGW (and thus Dev-C++), Visual C++ Toolkit 2003, GNU C++, and so on, fixing any incompatibilities that may arise...

about multiple platforms - i originally intended to release for both windows and linux originally, but i simply do not know how to code for linux beyond hello world console apps. if anyone wants to do a port, or collaborate with me, i welcome them with open arms.

about licensing and engine issues, you can see Irrlicht's license at http://irrlicht.sourceforge.net/license.html - its about one paragraph, very unrestrictive, simply incredible. perfect for rf, imo. irrlicht can run on windows, linux, etc perfectly, so rf2 would, if i could not find anyone to work with me on linux code, be easy to port should someone come along awhile into it. i'll look into ways to mark off win32 specific areas, be it with ifdef's, etc. so that the code should theoretically compile on linux with no issues, though things like error message boxes and the editors wouldnt work without coding. another option is to use wxwidgets instead of win32, though i dont know if it would be possible to get irrlicht running in a wx window for things like the level editor and other things i have planned.

I'm thinking if we make a tool that can convert .3dt to the new format, then we would still technically be using something from Genesis3D and thus still have to show the logo and such

we should be able to use the converting tool without the genesis logo as milkshape converts the files without the need to use the genesis logo, i may also be wrong but im sure if milkshape can do it we can!

good point. there also may be some issues with using the 3dt format however - i do not know just how model-based rf2 will be. i need to do some research before i can say for sure. one thing i can almost say for sure is that bsp will be dumped for octree. if i spend extra time making a visibility compiler for 3dt to strip the unused faces, it should work.

alot of research will need to be put into the editor/level format in particular.

Will the real Pickles please stand up... (can't, he took some pills) LOL!

Another RF2 eh? Cool. Just for the record though guys, everyone who posts guest isn't always me, but thanks for thinking about me! lol.

My opinion in ths matter is just do it. Just do it. It's all good if a person justs gets up and does it and keeps at it. Personally I agree with the whole not using a base code thing since that's my apraoch too, but it definetly would make the whole process quicker. So there's an advantage right there.

I've played around with irrlicht ane have been an advocate of it being used for an RF2 code base for a long time. It's a good choice I guess.

Anyways, ley me go check out this BV demo....

If i were you i would dump the 3dt and actor model formats! It is waht always ticked me off about rf. Back in my early game dev days compiling an actor file using milkshape and actor studio was a pain...especially when getting textures working!. If you want nice looking models and skeletal animation i suggest md5 (I am the guy who posted about q2e...no i am not obsessed )



I you want a format more like the old rf I would suggest a halflife mdl or halflife 2 mdl.

md5 is easier to make and more common. I use them and make them in milkshape but you can use max or even gmax! You could also go back to md3 if you wanted to use fraim animations but ....welll...ya dont do that!.

as for you map format. You said you were getting rid of bsp...how does octrees work. What file format is it. what is an example of something that uses it.

As far a q2e if you can get paralax mapping in your engine and stuff like that then your better off. I was just giving you fps guys an easy way out. Are you looking for mor like farcry capiblilitys like large terrein rendering?
I you just wanted paralax mapping its an easy add to a engine like q2e (whos source code is online!)

I look forward to seeing your update! RF was my beginning! and who knows if you guys beat q2e graphic wise I might migrate back! Personally though i find modding a quake based engine easier then RF but the main downfall is it is good for inside buildings not outdoors and q2e can be great for dark games and even some nice happy games but you have to get used to ppl.