Reality Factory

Not going to say just yet, but it should speed up RF2 development quite a bit.

I do not know. I had it quite a ways (majority of the menu code done, inis loading and log file writing, window rendering stuff, etc), but I do not yet know how much of that will have to be scrapped/reworked to fit in with the new design.

No, it will not. BUT, what it does is if it is not a valid size (power of two), it will automatically scale it down or up to match a valid size (its a video card problem, not much I can do about it really). This will result in a degradation of quality, but at least you can use odd sized textures now.

Progress is coming great, I just got my new 'stuff' integrated with Irrlicht and am able to set the game resolution using the new system. Now I just need to integrate the rest of RF2.

do you really need me to work on a g.u.i?what i mean is----for an rfeditpro-like editor?or do you have that going as well?

It's up to you - I have no such project in the works, and it will still be an integral part of RF2.

well----we can't use the current one....unless we just use the .3ds export of it, and trying to replace all genesis3d related stuff in it looks to be a lot harder than coding a new one from scratch.....

Yes, I definitly agree. We will need to rewrite RFEditPro using WXWidgets for RF2.

If you don't mind I would like to help on this endevour.
I switched back to windows, after formatting my hard-drive who knows how many times trying to get both windows and mandriva on at the same time, I decided to wait on mandriva and just use win98. Almost a month with-out programming any c++.

Should we just create a new file format?



[/code]

If you don't mind I would like to help on this endevour.
I switched back to windows, after formatting my hard-drive who knows how many times trying to get both windows and mandriva on at the same time, I decided to wait on mandriva and just use win98. Almost a month with-out programming any c++.

Should we just create a new file format?

As I see it you would need editpro to write 2 types of files

1. the map file type be it BSP or what ever.

and

2. an entity file , most likely as a python script

then again I could be wrong as i don't know which way Andy is going to do it, as at the moment Irr dosen't read entitys from a bsp file, but from the main c++ script you have to create for your game.

THEN AGAIN I COULD BE WRONG.

Ps it's great been over (18 in Ireland, 21 in the U.S and maybe in Can.) I can have something stronger then tea, 4.6% stronger.

well everyone seems to be taking the advice of continuing with the current reality factory instead of waiting for RF 2

i am just wondering if andy could give us an update on whats happening if you have the time that is.

Thank goodness they did.

Right now, David is adding audio and I am revamping some internal code to be more effecient and cleaner.

(EDIT: Belated happy 1,000th post!)

lol, i was gona post a congratulations on general descution but with the site being down i sort of missed your 1000th post.

I have an idea about the file format:

Maybe we could make the editor so that it writes x-files, and the EntityScriptFile would then load them. This way prefabs could be reused. Also this allows us to reuse textures, which would be packed before by a texture packer. This way we can save lots of disk space in relation to RF1.

It would be possible to form 'groups'. Each group would be exported as one seperate x-file. This also makes culling easier for the engine, since Irrlicht culls all meshes with AABB-Box-Culling against each other, as far as i understand it.

Also it allows certain optimizations, because if all polys of a certain group have the same texture, then it's just faster (because the mesh then can be rendered in one pass) than if they have more than one texture.
As a side note, this is also the reason why a model should only have one texture and be using uv mapping instead of multiple textures at one time.

Another pro is that it would make the editor very flexible because StaticMeshes/SEPs could be easily converted into levelgeometry with one click. In fact there would be no need for them anymore, because level geometry would be treated like entities for the engine.

Yup, enough said for now.

Maybe i could help with an editor...
im not a programmer, but a good designer. I work at a design studio and im often designing interfaces (ok mainly for websites...)
But if anybody wants support in this area i can help.

I coul write a design script that explains and structurizes gui elements. i could also do a design doc for the programmers so they know where to place buttons, menues etc...

I have seen the interface of the menu builder by steven8. And this is a great interface! The interface of beyond virtual is great too! One window with tabs for different tasks. I imagine an editor with tabs for levelediting, actorviewer, texture packer, scripting, menue, hud, effects...

i hop it is clear what im saying, my english is a bit rusty...

So, if someone needs help in such a "desinging process" im here to help.

Feel free to contact me at: kontakt@michaelhurler.de

@Andy:
for me as a Non-Programmer it sound incredible what you are doing!
Keep up your great work!

Cheers

am i correct in saying that RF2 is defenetly going to be a next generation engine? or is it going to be just an advanced engine compared to the current market?

*edit
the reason i ask was for the logo idea but i didnt bother waiting for a response i was bored so shoved it on anyway, if it not a true next generation engine then i can remove this from the logo i created.