• Advertisement

Archived

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

A New Way to Code Games!

This topic is 6248 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

well this probably isn''t a new way to code a game, (there are probably 9,000,000 things wrong with it or 9,000,000 people already doing it) but i thought of it myself. Ok say we make our whole outdoor landscape and trees and bridges and buildings and EVERYTHING in one Cinema 4D / Bryce 4 / 3D Studio / whatever file. So basically what I have is a 3D world made with one of these 3D Modeling / Animation programs. Now I export it to Microsoft''s .x format. Now what we have is a mesh file with all the textures and everything in it except for any models that move. Now you load in that .x file as a skinned mesh into a DirectX program. So what we have now is the world we made in Cinema 4D (or whatever program that can export to .x format) in a direct3d rendering window! Things to look at: 1) The only code to do this would be a simple mesh loading function. An entire 3D Engine could be coded in a few weeks by only two or three programmers. 2) Movement would be just like normal, just make the camera respond to the mouse / keyboard. 3) Colision Detection and Y-Correction would be disgustingly easy due to the D3DXIntersect function that is in D3D8. (For anybody that doesn''t know what Y-Correction is, its an algorythm that will correct the camera''s Y positioning depending on the height of the surface on which you are standing) 4) Speed and Optimization. With Direct3D 8.0''s endless list of mesh optimizing functions, i can''t see this being a problem. 5) You wouldn''t worry about having to make a level editor, just use Cinema 4D. I have thought of this for a while and it seems flawless to me. I don''t believe that I am going to start a new revolution with this, there has to be something wrong. There has to be a reason why nobody is using this method. If anybody likes this idea or knows if it will work or not, or if I am missing something, let me know. Thanks alot.

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
I could be wrong, but transforming an entire world each frame, hmmm? I hope it''s a small world

Share this post


Link to post
Share on other sites
no but that is what those mesh optimization functions are for

besides, that is all any terrain engine is doing anyways

and im sure that you could fix it up so that it loads new data in if you walk too far

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I don''t know about these optimization functions, I can only find one and all that does it resort the polygons to cut down on state changes.

Share this post


Link to post
Share on other sites
yes, there are flaws. If you load the scene as one big x file, you will be rendering one big x-file. Therefore you cant cull models. You can cull polys, but you will have to test every poly and then you''d have to write your own x-file rendering routine and create new VB''s. You will also have to test for collision against all polys.

The pros usually create heirarchial scene graphs.

Your idea might work for a demo or sample.

Again its slow to throw all your polys at the card. You want to do some quick visibility tests first.

ECKILLER

Share this post


Link to post
Share on other sites
ive spotted a tennsy flaw
IT''LL RUN ABOUT 1FPS ON A ATHLON1000

http://members.xoom.com/myBollux

Share this post


Link to post
Share on other sites
trespasser tried this approach; read the postmortem on gamasutra to see why it didnt work...plus, this approach would make your world necessarily static, and where''s the fun in that?

<(o)>

Share this post


Link to post
Share on other sites
Its not a completely new idea, because I''m already doing that. (Not exactly like you''ve described though)



Demetrios Georgeadis
Director/Programmer
Oniera Software Artists

www.oniera.com


Share this post


Link to post
Share on other sites
By the way, I agree with you, I believe this method to be much better than the alternatives...


Demetrios Georgeadis
Director/Programmer
Oniera Software Artists

www.oniera.com


Share this post


Link to post
Share on other sites
PSioNiC
I think that is a very good idea, it''s almost exactly what I am doing.
I have put together my own X file import routine that dosn''t use any of DirectX''s functions. X files support parent/child objects so its not hard at all to cull out objects(or terrain) that is not visible. I''m using TrueSpace for all of my work since it both reads and writes X files. It only has support for Linked animations(no skinned meshes) with the X format, but about 90% of all animations work that way so its no big deal.

Share this post


Link to post
Share on other sites
quote:
Original post by aDasTRa

trespasser tried this approach; read the postmortem on gamasutra to see why it didnt work...plus, this approach would make your world necessarily static, and where''s the fun in that?

<(o)>


Where can i find this postmortem. I don''t know Trespassers real name so it was a little hard to find it at Gamasutra. Want to give me (us) some direction?

Thanks

Share this post


Link to post
Share on other sites
zedzeek: any game will run 1FPS on and Athlon 1000 because AMD bites my @ss!

sorry i couldn''t resist

Share this post


Link to post
Share on other sites
quote:
Original post by PSioNiC

zedzeek: any game will run 1FPS on and Athlon 1000 because AMD bites my @ss!

sorry i couldn''t resist


http://www6.tomshardware.com/cpu/00q4/001120/index.html

I''ll take a significantly cheaper AMD with an unoticable loss of performance over the overpriced competition. The P4 is an overpriced marketing-department driven product.

~S''Greth

Share this post


Link to post
Share on other sites
quote:
Original post by PSioNiC

zedzeek: any game will run 1FPS on and Athlon 1000 because AMD bites my @ss!

sorry i couldn''t resist


heh, and we''d still all believe the sun revolves around the earth if we hadn''t tried something new and found out it was better.

Pentium''s are a waste of money and time. Get out of the trend and get a real processor.

Sorry, I couldn''t resist

CodeMonkey

Share this post


Link to post
Share on other sites
Hmmm.. well is not a bad Idea (I actually did it once), but the problem is... consider this, (based on a gamasutra example) lets suppose your game is set on the insides of an airplane, you have a model (1000 polies)representing a seat, and then you take this aproach, if your airplane has 200 seats or so, just for all the seats in the plane you will be rendering and transforming 200,000 polies each frame. Thats 600,000 vertices. without counting any other model...

Now.. lets suppose that you split your airplane in sections (we will call this portals) and then you split again this section in a structure where you can cull any polygon that you are actually not seing at the time (we will call this procedure BSP or whatever) then you will just render I dont know 20,000 polies per frame, plus since you divided the plane in sections you can cull those sections you arent using at all, cutting it down to 5000 polies per frame... now do the math, what can you do faster render 200,000 polies or 5,000 ?

However, if you add all the polies again, you will have the same 200,000 polies 3D MODEL, the reason why we use level editors instead of model editors to do them, is because is actually easier to do it that way, since the level editor is made exclusively for that it has better tools and functions with that purpose , but you could use 3dmax to do it if you wanted to. (have you heard of quake2bsp for 3ds max?)

You see, we dont do this BSP and PORTALS and TERRAINS, math culling because is a lot of fun and we simply cant keep ourselves from adding hundred of hours of designing and extra coding and sleepless nights to our projects...
We do it because it will render faster, be more efficient, do more features, and there for kick more ass. Plus it does things that are basically impossible with other methods, like rendering 200 seats in an airplane.

It might not be that fun to code for, but is fun to play with.=)

PLUS, is possible (if not easier) to check collision detections against this kind of sectioned models

Now, terrains are models too, but ther are created somehow on REAL TIME based on a heightmap or fractals or noise,etc instead of modeled in max , (AND you can use bryce to do heightmaps too).
Actually since terrains can be generated on realtime, by using the right functions, they can be actually INFINITE, can you model something infinite?, nope you simply can''t..

So, the morale is this , you can, and it works trying to render a single world model for any game. But if you divide your model somehow, in order to only show what you need, your world model can be larger more detailed and render a lot faster...

Now BSP,PVS, OCT-TREES, QUADTREES and HEIGHTMAPS are just the standards we use for doing this, but you can use anything that works for your game, they are TONS of ways of culling objects and levels. And whatever works for you faster, is the best! =)

Comment.. boy, I would have really apreciate it, if someone had told me this when I was a newbie.

I hope this helps...

Share this post


Link to post
Share on other sites
ya i see what you are saying about the culling problem, however alot of video card drivers do this for you. I know my Voodoo5 driver does it. I''m sure there are others.

about the terrain thing, all you have to do is just make the height field wrap seamlessly any you have yourself an infinite level.

im sure you could find a way to edit the mesh in real-time so that you aren''t rendering things that you can''t see.

i think the optimization functions are only in DX8 (don''t mark my word). Those functions i think clean up that culling problem (again don''t mark my word)

i''ll take your ideas into consideration. From what i have heard from other people i don''t know if you are entirely correct. i understand the point that you are raising though.



oh and codemonkey, how are you liking your single-processor system? what? no dual or quad AMD systems? sorry buddy but there is a difference between a buff guy who comes in to a LAN party with a dual xeon system and a little nerd who walks into a LAN party with a pesky uni-processor system that he bought at future shop. Its just not the same.

Share this post


Link to post
Share on other sites
Yes, the drivers of almost every video card will cull polys for you. The problem comes in that you still have to send each and every single polygon to the video card before it can determine whether it needs to cull it. And in the case of your Voodoo 5, every single one of those polygons has to be transformed, and lit, by either you or the Direct3D runtime before it can be determined whether it needs to be culled. That's a lot of wasted processor time.

Then you take a system like an Octree or a BSP, where with one simple test, you can cut out half the number of polygons you need to check. No problem. Perform more of those simple tests, and you come down to culling just about everything you need to before you transform it and send it to the card. So now, you actually have processor time left to do the important stuff, like implement gameplay. Isn't that more important than how easy it was for you to draw things?

Jonathan

P.S. - Oh, and regarding the processors. Why in the name of all things holy do you need a dual-Xeon system to play games? I work on a single P3-800 at work, with a TNT 2 M64, and everything is more than fast enough for my tastes Seems like a big waste of money to me.

Edited by - Jonathan on January 15, 2001 7:00:37 PM

Share this post


Link to post
Share on other sites
for the trespasser postmortem, head over to www.gamasutra.com and just search for it; that is what the game is called...

last night after i posted my last reply i had some ideas id thought id share...

1. if the entire world is one object when you process it you''ll do the entire thing, include stuff behind you, stuff outside the view frustrum, and stuff that is occluded. now if you eliminate that info, well you''re half way to coding a visibility algorithm anyways...y not finish the job?

2. imagine trying to make even the most slight of changes to the world...say for instance two pillars of stone side by side. you may place them in the modeling program, save the entire world, then convert it to your format, start up your engine and load the object in, go to the pillars and...decide they are too close together...so you exit the engine, load up the modeller, load up the huge world file again, make the slight change, save it, convert it, etc. maybe this time they are too far apart though...you get the picture i think.

3. load and save times would be horrendous; nuf said i think

4. everything in the world must be placed, textured, lit, etc by hand in the modeller. this might be fine for the sahara desert at noon scene, but what about a forest? image modelling and placing every individual tree one by one by hand. if you were some what ingenious with a level editor you could code some algorithms to randomly generate trees and place them in an alloted area, automating the monotonous process of hand placing. also, texturing surfaces would be brutal in your idea because each poly would have to have it''s own texture mapped in the modeller. in a well designed editor you could simply have the textures tiled on similar surfaces, reducing your work and texture storage space, among others...

i guess what im trying to say is i personally think your''s is a bad way of doing things...but i must give you credit for swimming against the stream a bit and thinking about a different way of doing things...

<(o)>

Share this post


Link to post
Share on other sites
quote:
Original post by PSioNiC

ya i see what you are saying about the culling problem, however alot of video card drivers do this for you. I know my Voodoo5 driver does it. I''m sure there are others.


oh and codemonkey, how are you liking your single-processor system? what? no dual or quad AMD systems? sorry buddy but there is a difference between a buff guy who comes in to a LAN party with a dual xeon system and a little nerd who walks into a LAN party with a pesky uni-processor system that he bought at future shop. Its just not the same.


So your game runs on a Voodoo5, and perhaps requires some dual Zeon system, with 256MB of RAM. Now you''ve covered about 1% of your market space. If your planning on making a game that runs on more then one system configurion (not to mention one that requires a specific video card such as a Voodoo5) your in for problems. First problem: 3DFX isn''t "doing so well" if you check the stock market (and their business problems). So that''s probably a bad card to rely upon for your game to run correctly because "hardware support" is there for your culling problem. Take the advance Azrael for it seems he has a good grasp on what he''s saying, take the hard road and fix the problem completly, don''t rely on support that is not in 100% of cards that most people will have in. However if your just writing the game for fun, and don''t really plan on doing anything but learning, then your probaby not in such a bad position.

Oh, and what is the deal with multi-processor systems? Can I get a multi-processor AMD? Who cares? I can get three entire AMD systems for the price of your dual xeon. Now when I go to a LAN party I can bring two more friends! So I don''t have the power to render 10,000 Frames per second or whatever, but since I can only see around 32FPS with the naked eye I am not really in that bad of a position... Plus the LAN parties I go to are a little more realistic, and people look at you and go "why the hell did you spend all that money when my Quake III game is running just as well as yours?" Of course if your trying to support the CEO of Intel, and his board then your probably doing the right thing.

CodeMonkey

Share this post


Link to post
Share on other sites
say you load up the mesh into a vertex buffer, then you apply a matrix transformation, would the transformed coordinates lie in the vertex buffer?
I tested this with my OpenGL terrain engine. I loaded the data from the height map into the game, and then called glRotate functions, and the level rotated, but the coordinates did not change. I suspect that the transformed verticies are in down in the OpenGL driver not at the program level.
If it isn''t the same with directX, then it would be much easier to do the geometry clipping.

if anybody knows anything about this then post.

Share this post


Link to post
Share on other sites
that idea is REALLY bad. the dx8 optimization function don''t lower the vertex count, so you have to rotate all the verticies every time. the point of a terrain engine is to prevent this. it might not be a horible idea if you were to break the terrain up into a grid and load each grid into a mesh. then you could at least not draw the meshes that aren''t visible.

Share this post


Link to post
Share on other sites
About the processor thing, if it doesn''t work on my laptop, then it won''t sell.

If you have a lot of identical objects in your level (like three identical desks in a room, with several chairs and stuff in different places, it is going to waste memory and processor time if you have to store all those chairs and desks as part of the level when you could store them separately, have them fall over or explode (dynamite chairs like in GoldenEye, tee hee) when you shoot them etc, you are going to have to make them separate objects, and not part of the level. The idea works up to a point, but if you want to do some really cool stuff it sort of breaks down. It reminds me a bit of the approach to 2D scrolling games someone used, make one big bitmap for the whole level and use a vector map for collision detection. Although it''s not an exact parallel, it sums up the spirit of the thing.



Just because you''re outnumbered doesn''t mean you''re wrong.


sharewaregames.20m.com

Share this post


Link to post
Share on other sites
I don''t know how many of you have really looked closely at the .X file format. But it fully supports Parent/Child heierarchys. It does not have to export 3dObjects as a single large mesh. You can very easily export an entire level in one file and still keep and treat each sub object as a seperate entity. You can also group a set of objects (chair/table/tree whatever) to a room or certain portion of your terrain, attach a visibility sphere to the room/terrain, and very quickly cull it and all of its children if its not visible.
I agree that in most cases a BSP/Oct/Quad or Beam tree would be better/faster. But... someones got to be the lab rat otherwise nothing new will ever be developed.

Share this post


Link to post
Share on other sites
about the mesh optimzation thing, i can''t remember who posted but he/she is wrong. The function that lowers the vertex count is D3DXSimplifyMesh

you can specify how far you want to simplify and everything

Share this post


Link to post
Share on other sites

  • Advertisement