Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Keeping the GPU on its toes  (Read 2392 times)
0 Members and 1 Guest are viewing this topic.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Posted 2002-10-26 11:31:17 »

From everything i've read on 3d programming, the main problems seem to be sending the info in the best way to the GPU to keep it constantly working, as opposed to waiting for texture uploads, state changes, readbacks (ack!) etc. Note i'm thinking from an openGL viewpoint here..

As I currently see things, theres several important factors, namely:

  • Minimising texture switching, seems to be a major point from what i've heard, switching vertex/pixel shaders being the only operation thats more expensive it seems (but shaders are out of my hardware range so i'm ignoring these for now). I assume the high cost is that the texture has to be transfered accross the AGP bus.
  • Static/compiled geometry. I've been seriously surprised how much this can speed things up, however good it may be it contradicts many other points (and i can't do my own lighting calculations, boo, hiss).
  • View culling. Important technique, but again seems to contradict with using compiled geometry.

I've probably missed somethings that others will rank as important, but for the time being these are what i'm trying to concentrate on. I'm going to keep things simple and have a top-down tile/iso/hex type engine, but i can't seem to come up with a design that manages to neatly deal will all of the above without excessive amounts of processing before the actual rendering. I've got a few half ideas at the moment, but i'd like to hear some other opinions first.

Cheers

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 378
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #1 - Posted 2002-10-26 21:47:51 »

Well, you're basically dead on target. Designing the bit that gets the best out of it all is indeed the difficult part.

It used to be that texture uploads were potentially the most expensive but these days you really want to make sure your geometry is culled to the minimum necessary to avoid overdraw. The thing is, they're all expensive operations but the expense varies greatly between cards, so you really have to do you best to minimise everything.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #2 - Posted 2002-10-27 06:24:14 »

After much metaphorical beard scratching, I think i'll be able to get some pretty good view clipping with a portal-eque system of interconnected cells (which would probably be good for ai as well if i got that far). Still plenty of grey areas though..

Does filling up a vertex array for each texture per frame sound like too much overhead? Basically find all visible tris, bung all of texture 1 in a vertex array and render, repeat for all of the rest of the textures..


[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Jeff

JGO Coder




Got any cats?


« Reply #3 - Posted 2002-10-28 03:11:57 »

So Java3D has a fair bit of wizardry in it in just these areas.

It does efficient view-frsutrum culling, compiles and optimizes the scene graph tree, and does state-sorting in order to minimize those nasty GPU context switches.

For details of how this is all done though you have to ask our Wizard-of-3D, Doug Twilleager.

JK

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2002-10-28 09:54:40 »

On a side note, yesterday my copy of '3D engine design' ( http://www.gamedev.net/columns/books/featuredbook.asp?productid=101 ) and frankly i'm not impressed  Angry

A much more accurate title would be '3d collision detection', since practically all of the book is testing collision of X against Y. Now while i may at some point need to calculate the intersection of a lozenge against a capsule, its really not what was promised. And theres but a single page on portal visibility, and a measly 3 on bsp's. And the only info i can find on this thread topic is but a single sentance: 'Then the Renderer can sort the objects to minimise state switching'.

/rant.

Maybe a section on the site for book recommendations etc. similar to the one over at flipcode would be a good idea?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #5 - Posted 2002-10-28 11:17:36 »

Designing a 3D engine always is to find a good tradeoff for various optimums. Some optimizations are mutually exclusive - which always leads to different engines for different purposes.

More geometry? More lighting? More textures? Bigger scenes? More effects?

Take any two of these.....

If the GPU has to change textures, it not only has to be loaded from main memory (in the worst case), but it also stalls the pipeline (at least in earlier days when I dealt with these things). So better sort for textures. But also sort for transparency (which break texture sort). And also sort geometry (which breaks texture and transparency sorts).

So it's no wonder that there are indoor engines, outdoor engines, flightsim engines, ....

I love the idea that there is an engine that cares about these things for me. And I hope that Java3D does (and I feel it does better than I could do!).

I hope I never need to go down to OpenGL again....


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (19 views)
2014-09-19 03:14:18

Dwinin (34 views)
2014-09-12 09:08:26

Norakomi (62 views)
2014-09-10 13:57:51

TehJavaDev (84 views)
2014-09-10 06:39:09

Tekkerue (42 views)
2014-09-09 02:24:56

mitcheeb (64 views)
2014-09-08 06:06:29

BurntPizza (47 views)
2014-09-07 01:13:42

Longarmx (35 views)
2014-09-07 01:12:14

Longarmx (39 views)
2014-09-07 01:11:22

Longarmx (36 views)
2014-09-07 01:10:19
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!