Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (739)
Games in Android Showcase (224)
games submitted by our members
Games in WIP (820)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  Vote for Structs!  (Read 20806 times)
0 Members and 1 Guest are viewing this topic.
Offline chronos

Senior Newbie

« Reply #60 - Posted 2006-03-09 16:53:15 »

So it's a question of how much vertex data your pushing around? If it is, how much more can I push? And should I care if  all I'm doing is making small games with under 50k polygons?
Offline Riven

« JGO Overlord »

Medals: 1313
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #61 - Posted 2006-03-09 17:06:01 »

First, we have the same idea about the struct-API.
Second, I see LWJGL as a binding to OpenGL/input.

So LWJGL will not benefit from structs, only the engines written around the wrappers, that do particle-engines for example, will benefit from structs.

I'm going to look for my Struct-classes, and see what the performance is. Last time I checked it was 50% of field-access... Roll Eyes

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline chronos

Senior Newbie

« Reply #62 - Posted 2006-03-09 17:12:04 »

IIRC The last particle engine I made used a interleaved array and had a lot of put statements, probably would have been better with structs...
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #63 - Posted 2006-03-09 17:33:21 »

IMHO the speed issue is secondary - I have a tendancy to be lazy and just duplicate the structures (so I'll have a bunch of objects which are the actual state, and these get pushed into a buffer as needed for rendering/io). The alternative of trying to keep the structures themselves in buffers ends up with clunky, awkward and error prone code which requires lots of superflours typing. And of course I've wasted a fair chunk of memory by having this duplication.

But of course I'm only doing low-poly 2d work. Even my most over the top particle systems don't top 512 particles.

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline chronos

Senior Newbie

« Reply #64 - Posted 2006-03-09 17:51:23 »

I do the same thing, I store all my particles in an array of Vertex and put them in a buffer every frame. I think structs would help me out here, but only if I needed a lot more particles. I'd have to do the same thing for animated models, so structs might help there too.. Btw why is your particle system size a power of two? Is this really necessary?
Offline Orangy Tang

JGO Kernel

Medals: 57
Projects: 11

Monkey for a head

« Reply #65 - Posted 2006-03-09 18:08:21 »

Btw why is your particle system size a power of two? Is this really necessary?
It's probably not really nessesary, bit of a C/C++ hangover there. Smiley

[ - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline chronos

Senior Newbie

« Reply #66 - Posted 2006-03-09 18:25:55 »

I'm also a fan of powers of two  Wink
Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #67 - Posted 2006-03-21 17:41:53 »

Since I'm far too lazy to maintain a proper website at the moment...I wrote an impromptu monologue the other week on structs, at far too late/early in the morning. Might be crap. Seemed to make sense at the time Wink.

I've bit the bullet, and started a blogger account. Will dig out the missing 2nd half of this (only a couple of paras IIRC) or just rewrite it, and post asap. Possibly in the next half hour, if I dont get distracted Wink.

malloc will be first against the wall when the revolution comes...
Offline Mr_Light

Senior Devvie

Medals: 1


« Reply #68 - Posted 2006-03-26 01:03:05 »

lets see if I get this right.

so you want to pull non-jvm memory into the jvm. from a within-the-jvm-perspective(the developers perspective/the OO kinda thing/the code) there is only Non-jvm memory since you don't handle jvm-memory from inside the jvm (and,as noted, you never should) so it's save to reguard and refer to non-jvm from within-the-jvm simply as memory since thats the only type of memory known inside the jvm. perhaps I should grant you some whitespaces to let that sink in.

ok Now we could declare a class Memory to create an abstract representation of memory. Now we don't want to dance with the whole memory just parts. hmm what to name those parts? Wenn figuring out a name a good name it useally helps to ask youself what you do with the object we read and write a to part or subsection/subcollection of the memory. Hmm read write isn't that input an output? now the obivous question that comes from this is how do we call a subsection of memory that we use for input and output: oi offcourse a buffer.

now the ppl paying attention will note how we already have that in NIO. and since we can obtain already buffers we don't need to write new code. (so we can trash that Memory class)

for the actual problem/issue the separate primitives that you can get from the buffer and are pritty meanless and simply don't fit in our OO world. We don't want do deal with indexes as an developer we deal with Ordered and unordered Elements/Objects, choosing ordered or unorded depending on if the order has added value. things like memory adress or the index on top of that existing buffer(because of the buffer already abstracting away memory adresses)  are meaningless. We want objects  that hold a few elements resp variables resp fields that abstractly represent something like a Coordinate Vertex Population or what not. We want the object and we want it to be in the memory.

from the memory perspective there are no objects there is an index(memory adress) and a value. So in order to get what we want we must Map the value and multiplex it to an Object. multiplex? you might think well yeah we strip the index/indentifier infavor for a posision or hierarchy overviewed by the as the position seperates them/ makes them indentifiable from eachother(instead of the index). 

In a nutshell what we want is a mapping of a collection of a group of values where we want that group to be astractly represented as an Object in our code.

now as someone already correcly noted this creates a lot of Objects. Objects that only hold a couple of state's which seem to perfectly lent themselfs to apply the flyweight pattern to.

ok guys if that didn't make any sense it could be any of the following reasons:
* I didn't get it, so it's incorrect.
* I was sleepy so I made mistakes which lead to inconsistency and what not
* my formulation sucks
I'm gonna reread it in the morning and edit it, good night.

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Pages: 1 2 [3]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

Ecumene (48 views)
2017-09-30 02:57:34

theagentd (72 views)
2017-09-26 18:23:31

cybrmynd (182 views)
2017-08-02 12:28:51

cybrmynd (180 views)
2017-08-02 12:19:43

cybrmynd (187 views)
2017-08-02 12:18:09

Sralse (192 views)
2017-07-25 17:13:48

Archive (744 views)
2017-04-27 17:45:51

buddyBro (876 views)
2017-04-05 03:38:00

CopyableCougar4 (1423 views)
2017-03-24 15:39:42

theagentd (1316 views)
2017-03-24 15:32:08
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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‑
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!