|
ZombieApostate posted:Fuuuuuuuuck I hate programming sometimes. I just spent several days trying to figure out what went wrong in my conversion from OpenGL 2.x to 3.x and vertex arrays to VBOs/VAOs. Not only did my research leave me with an rear end backward impression of how VAOs are supposed to work, but I introduced a stupid little vertex index offset bug and every time I started to investigate one possibility, it started to look like the other was actually the problem. I had the same problems switching from old fixed function immediate mode to 4.1. It also took me forever to get anything working, the exact same issues with DrawElements and VAO/VBO problems. Next is to get textures working using shaders. There is very little information on opengl, at least information that is up to date and correct.
|
# ? Sep 2, 2011 07:20 |
|
|
# ? May 13, 2024 11:20 |
|
For the standard vertex array (without compiling them into an object) you need to send a pointer to the vertex buffer. When you compile them into a VBO then instead you pass an offset. Really it's not your fault, it's (in my opinion) a bad API design. Sounds what you really need is a better process for debugging to make sure that you're not really tackling two problems at once. That's where you get yourself in trouble, you need to figure out how to isolate and solve one problem at a time. When bugs add up they become impervious to logic and reason.
|
# ? Sep 2, 2011 08:02 |
|
Vino posted:For the standard vertex array (without compiling them into an object) you need to send a pointer to the vertex buffer. When you compile them into a VBO then instead you pass an offset. Really it's not your fault, it's (in my opinion) a bad API design. Sounds what you really need is a better process for debugging to make sure that you're not really tackling two problems at once. That's where you get yourself in trouble, you need to figure out how to isolate and solve one problem at a time. When bugs add up they become impervious to logic and reason. I don't generally have a problem debugging if it's something reasonably familiar or I have docs to work from. It also didn't really help that I was coming up with reasonable sounding theories of what went wrong that turned out to only sound reasonable at 4AM. I stopped working on that after fixing the bugs for good reason, although it still hasn't helped me get to sleep.
|
# ? Sep 2, 2011 11:03 |
|
Yeah, that DrawElements offset thing is part of the VBO spec, not glDrawElements. OpenGL is still suffering documentation-wise due to being bogged down with legacy and expanded-since-publication features that only continue to exist in their original form because of terrible CAD developers. Microsoft just deletes old poo poo from the API. I'm starting to think that D3D may be a better language to start with at the moment just because of how long they've let that problem fester, and because of how much the D3D API has improved usability-wise over the years. I still find it to be slightly more cumbersome (gently caress input assemblers), but it's so much better about not teaching bad habits. OneEightHundred fucked around with this message at 22:32 on Sep 2, 2011 |
# ? Sep 2, 2011 15:23 |
|
Yeah I have that problem too. Everything seems like a good idea at 4 am. Better to just go to sleep, the answer comes quickly in the morning.
|
# ? Sep 2, 2011 17:28 |
|
Dude I feel you on spending hours on phantom problems (that you cause yourself by forgetting to uncomment a line or something that stupid.) What are VBOs/VBAs?
|
# ? Sep 3, 2011 07:29 |
|
OneEightHundred has probably taught me more about OpenGL through this and the 3D programming thread than has any other source I could find.
|
# ? Sep 3, 2011 15:57 |
|
Physical posted:What are VBOs/VBAs?
|
# ? Sep 3, 2011 16:18 |
|
The "traffic cones" thing is actually pretty loose, they're as meant for dynamic geometry as they are for static. Just make sure you actually create them as dynamic if you're going to use them that way! Keep in mind that VBOs are yet another thing that was added to mimic functionality that D3D already had, and at that point, D3D wouldn't even let you draw out of anything BUT vertex buffers, so they really are meant for all purposes. There's a distinct advantage in using them for dynamic in that you can use discards to indicate that you're done with the data you stuffed in it and, if you try to use that buffer again, it will give you a new memory region if it's not done using the old one. Using glDrawElements out of system memory on the other hand causes a stall to ensure that you don't overwrite the memory while it's trying to read it. You can signal that you're done with the data in a VBO by calling glBufferData on it with a NULL data pointer. So for example, my current framework basically does: code:
Oh yeah and don't memcpy into a VBO, you can do it but BufferSubData doesn't pollute the cache. Neither does _mm_stream_ps, of course, but then you have to learn SSE. Actually you should learn SSE because SSE is actually pretty easy to learn, is staggeringly faster than using floats, doesn't really require learning assembly because of intrinsics, and can be abstracted away using a Vec4 class in C++. OneEightHundred fucked around with this message at 18:22 on Sep 3, 2011 |
# ? Sep 3, 2011 18:11 |
|
OneEightHundred posted:Another thing to consider is hardware as recent as the GF 8800 don't even report 32-bit indexes as allowed to D3D, which usually means that OpenGL optimizes your 32-bit indexes into 16 and falls back to software if it can't. That has two implications: First is that using shorts for your indexes is probably a good idea, second is that it makes it pretty easy to set the maximum size of your dynamic VBO when you have a hard cap of 65535 verts! Wow, I had read that you should use 16 bit indices, but they never said why exactly. I guess that would be why they also suggested your vertex buffers not go over 4 megs, too. Anyway, I'm stuck on another thing I can't find any documentation on. CG shaders worked with OpenGL 2.x, but the only semantic I can seem to get bound properly is POSITION. glVertexAttribPointer and glEnableVertexAttribArray take an index that I think is supposed to be the index of the semantic you want them bound to, but I've never seen them referenced as anything but names. I've seen it mentioned that you could just use ATTR0, ATTR1, etc, but CG threw up compile errors about that. I'm at the point of just running through numbers until I find it, but even that isn't working. I could also be missing some CG function that I needed to add after the change, I suppose.
|
# ? Sep 3, 2011 19:51 |
|
Be extremely careful about mixing numbered attributes with legacy attributes like color, position, and texcoord. Attributes are NOT supposed to be aliased to things like position and texcoord, but they are on NVIDIA because NVIDIA blatantly hosed up and then refused to change the hosed up non-compliant behavior because there are apps depend on it. I couldn't make this up if I tried, but it's in the Cg reference manual somewhere, probably if you search for HPOS or ATTR0 enough times. Basically, either use numbered attributes for everything you pass into the VS (DO THIS) or respect their lovely aliasing behavior by not overlapping your attribute usage with their reservations. Don't bind attribute numbers to access non-numbered attribute streams or your app will explode on ATI hardware. The proper call for binding to position is glVertexPointer, but you should probably get in the habit of using only numbered attributes because built-in attributes are deprecated. Alternately, use GLSL. Mustach posted:OneEightHundred has probably taught me more about OpenGL through this and the 3D programming thread than has any other source I could find. A nice place to bounce questions around is #darkplaces on AnyNet (irc.anynet.org), it's kind of the main hang out for people doing engine mods for Quake-series engines and has several people who have worked on rendering tech. OneEightHundred fucked around with this message at 04:19 on Sep 4, 2011 |
# ? Sep 3, 2011 20:12 |
|
And the winner iiiissssss: I was doing everything right, except I didn't realize the ATTR semantics are only for vertex input and didn't read the CG error closely enough to see it was only complaining about the ones I had in the output structure. Derp. Fortunately (unfortunately?) I'm running on ATI hardware, so if anything is going to blow up horribly, I'll see it. I will definitely keep in mind to just use ATTR* for vertex inputs, though.
|
# ? Sep 3, 2011 22:00 |
|
I'm terrible at program structure/design and always end up with problems like these.. Right now I have a Main class which has an EntityManager and a MessagingSystem. The Main class calls upon the EntityManager to do things like moving Entities, and since the Main class doesn't keep track of all the Entities the EntityManager also checks for collisions. Now here's my problem; when the player (an Entity) collides with another Entity, I want that entity to call upon it's OnCollide() and add a message to the MessagingSystem... which it can't reach. I'm doing this in Python which makes everything even more confusing for me since I'm used to Java, but even with Java I always end up in situations like this. Getting all the classes to play nicely with each other without having to pass every single instance to the other classes in their respective constructors is proving to be too hard for me Any material on design problems like these would be greatly appreciated. I'm sure you're supposed to figure out these things yourself, but a sort of template to follow would sure be nice. e: Earlier, I've had similar problems when trying to do stuff based on keypresses etc. In this case, the Main class handles key events, so it's main -> entitymanager -> entity and then I want the entity to be able to do stuff to the main class again. Which I guess is a loop. Or something. I'm bad at this.. Your Computer fucked around with this message at 09:34 on Sep 5, 2011 |
# ? Sep 5, 2011 06:10 |
|
Your Computer posted:
I'm not quite sure how it goes in Python, but couldn't you add a "parentManager" EntityManager variable to the Entity class definition, and then set that to your running EntityManager when the Entity is added to it? That way, you can directly access the EntityManager, and if you give a reference to the Main class in the definition of the EntityManager, you might be able to directly influence Main from an Entity. Possibly ending up with something like this? thisThing.parentManager.parentMain.do_things(); Then again I have no idea if this is good or terrible practice since I'm stumbling on the same sort of issues myself.
|
# ? Sep 5, 2011 22:20 |
|
One of the basic design patterns that helps solve this is called a "Singleton". Being a 'singleton' means only one of these things per system exist, and normally anyone can ask it to do something. Some classic 'singletons' might be your sound system, or object factory. Typical C-like singleton pattern pseudocode might look like this: code:
The basic idea is to utilize 'static' members to present an interface to manage a single instance of an object that any other code can utilize. Just google 'singleton' and I'm sure you can find a better descrition than mine In general, a study of 'design patterns' can be really helpful. Unormal fucked around with this message at 22:37 on Sep 5, 2011 |
# ? Sep 5, 2011 22:34 |
|
Unormal posted:One of the basic design patterns that helps solve this is called a "Singleton". Being a 'singleton' means only one of these things per system exist, and normally anyone can ask it to do something. Some classic 'singletons' might be your sound system, or object factory.
|
# ? Sep 6, 2011 00:04 |
|
"static" doesn't mean that it never changes, that's "const" "static" means that there's only ever one global instantiation of that object no matter how many times the class is instantiated. So it plays right into a singleton because GetTheSoundSystem() will only ever return the same one.
|
# ? Sep 6, 2011 00:19 |
|
Vino posted:"static" doesn't mean that it never changes, that's "const"
|
# ? Sep 6, 2011 00:42 |
|
Physical posted:Oh yea, const and static aren't the same thing. A 'static' variable is basically just an old-school "global variable" that happens to live in the namespace of the class it's defined in.
|
# ? Sep 6, 2011 00:48 |
|
Ok, OpenGL 3.x is a go, shaders working, time to yell at my monitor over something else. I'm currently looking for a free GUI toolkit to integrate into my engine. So far my most promising options are: I really like the barebones-edness of GWEN and it looks like it is perfectly happy being only loosely tied into your engine. Maybe light on fancy pants features, though. Clutter has a link to a pretty sweet looking media browser somebody made with it that shows off some cool features that would be nice, but I haven't looked at it closely enough to see if it would integrate into a game engine nicely. Qt and GTK+ I'm reasonably familiar with, as a user at least, from various programs, but I think they would be a lot more bloat than I'm really looking for. And I don't really care about having the native OS interface look. Has anybody used any of these and have an opinion? Or something else I should look at?
|
# ? Sep 6, 2011 02:29 |
|
WxWidgets is a lot lighter weight than Qt and a lot better than any of the other options. Qt is great if you don't mind the all in nature of it. GWEN looks like an in-game UI sort of thing, which is kind of apples and oranges to what Qt/wxWidgets are for (tools.) edit: Clutter isn't even a UI toolkit, it's a backend for graphics which you could use to implement your own UI. So aside from GtK+ and Qt none of those libraries even do the same thing. Paniolo fucked around with this message at 04:40 on Sep 6, 2011 |
# ? Sep 6, 2011 04:06 |
|
Paniolo posted:WxWidgets is a lot lighter weight than Qt and a lot better than any of the other options. Hm. quote:GWEN looks like an in-game UI sort of thing, which is kind of apples and oranges to what Qt/wxWidgets are for (tools.) An in-game UI sort of thing is what I'm looking for. quote:edit: Clutter isn't even a UI toolkit, it's a backend for graphics which you could use to implement your own UI. Well poo poo. They don't make that very obvious. Looks like I'm leaning even more strongly toward GWEN then. There really don't seem to be that many options when it comes to in-game UI stuff. I know there's Crazy Eddie's, but I think it looks ugly and it was buggy as hell when we used it in school, so I'm not wildly excited about it.
|
# ? Sep 6, 2011 06:27 |
|
Still waiting for an opensource Scaleform clone... Gameswf is the closest thing I can find - and it looks like scaleform was actually based on it at one point - but it hasn't been touched in years and probably doesn't work very well with any modern authoring tools.
|
# ? Sep 6, 2011 06:51 |
|
Unormal posted:One of the basic design patterns that helps solve this is called a "Singleton". Being a 'singleton' means only one of these things per system exist, and normally anyone can ask it to do something. Some classic 'singletons' might be your sound system, or object factory. Thanks, I'll check it out! I haven't actually ever bothered to get into singletons because I've heard a lot of people badmouthing the practice. What are the pros/cons of such an approach?
|
# ? Sep 6, 2011 13:56 |
|
Your Computer posted:Thanks, I'll check it out! I haven't actually ever bothered to get into singletons because I've heard a lot of people badmouthing the practice. What are the pros/cons of such an approach? Pros: Your software works in a simple, understandable way. Cons: Purist dummies will badmouth your practice.
|
# ? Sep 6, 2011 14:56 |
|
Unormal posted:Pros: Your software works in a simple, understandable way. There are good reasons to avoid singletons. However, few of them apply if you're working solo and not writing unit tests. I'll factor singletons and globals out of code at work and then come home and use them in my personal projects.
|
# ? Sep 6, 2011 15:26 |
|
Unormal posted:Pros: Your software works in a simple, understandable way. That being said, it is sometimes okay to use globals, but you should really spend a little extra time thinking about them each time. Ask yourself the question, would I ever want two of these at once? For example, let's say you've decided to write your SoundManager as a Singleton. It has one method, 'PlaySound(string name)'. Cool, everything works. Now let's say you start adding underwater sections to your game, and you decide that your SoundManager needs some kind of pitch adjuster to make all sounds played sound under-watery. So you add 'AdjustPitch(int pitch)' to your SoundManager, which changes how everything sounds. You call AdjustPitch when you go underwater, and then again when you resurface. But what about other sub-systems, such as your menus (maybe you press escape and navigate some menu options and each of them makes sounds)? Since you're using a global sound system, it'll have the messed up pitches. If you had two instances of SoundManager, this wouldn't be a problem--each subsystem could have it's own configuration. Of course, this could be solved by having PlaySound take in some sort of configuration object which contains the pitch and other parameters to modify the sound (duration, echo, other effects) and each subsystem manages its own configuration. Or you could just ditch the Singleton altogether, since you're passing around these configuration objects anyway--just make those objects the instances of SoundManager. Another example is an InputManager, which you might be tempted to use a Singleton for, until you realize you want to add local multiplayer to your game and have a bear of a time fixing everything.
|
# ? Sep 6, 2011 16:18 |
|
Paniolo posted:Still waiting for an opensource Scaleform clone... Gameswf is the closest thing I can find - and it looks like scaleform was actually based on it at one point - but it hasn't been touched in years and probably doesn't work very well with any modern authoring tools. The main thing stopping it is lack of necessity, HUDs are not hard to create using subscenes and menus are not hard to create with a basic DIY control kit and scripts. It's only when you get into highly complicated animated menus that Flash starts becoming necessary. OneEightHundred fucked around with this message at 16:54 on Sep 6, 2011 |
# ? Sep 6, 2011 16:31 |
|
It's really easy to rework a singleton class into a non-singleton class. Use a singleton until you realize you need a non-singleton and then change it. The purist grognard dummies I find often overestimate the simple task of rearranging code to suit new purposes. Many programmers would rather over-engineer, ugh.
|
# ? Sep 6, 2011 19:15 |
|
So far in my own dabbling around with game engines I've found a few things that have come out to be global constructs. One is all the subsystems, which I originally wrapped into a singleton, and then the entity manager. I ended up actually taking out the subsystem singleton because part of the interface I wrote had components get a handle to it at a specific time, so that way I know that only at that point would a component get to muck around with the subsystems. Anyways it's true that it's easy enough to refactor. The code is basically already written, but just has to get moved around. For the problem at hand, I wonder why the messaging system is not a part of the entity manager. If messaging happens across entities, then at the 40,000 foot level, it would make sense to me the entity manager would take care of these interactions.
|
# ? Sep 6, 2011 19:44 |
|
OneEightHundred posted:Personally I've never understood how the earliest Unreal could find time to pack in a full-fledged desktop-style windowing UI (and an IRC client and a simple web browser), and now we get games like UT3 and Bad Company 2 that need to onboard a Flash developer for dumb page-flipping menus with no moving objects. (Actually BC2 has one thing moving, the background scales in and out, woooo) I don't think you're looking at it from a designer's perspective - Flash has an excellent ecosystem of tools, resources, and talent, and the ubiquity of Scaleform is largely due to the fact that you can easily hire a designer who already knows Flash and can get to work right away instead of having to learn whatever custom system you have in place and constantly pester your programmers.
|
# ? Sep 6, 2011 20:15 |
|
Paniolo posted:I don't think you're looking at it from a designer's perspective - Flash has an excellent ecosystem of tools, resources, and talent, and the ubiquity of Scaleform is largely due to the fact that you can easily hire a designer who already knows Flash and can get to work right away instead of having to learn whatever custom system you have in place and constantly pester your programmers. In certain cases it is, but there other ways to deal with UI complexity regardless, especially as bolt-ons to scene management, particle animation, and entity scripting. My initial point was that the main reason there is no open-source alternative is because "roll your own" is already a plenty-viable alternative. OneEightHundred fucked around with this message at 04:22 on Sep 7, 2011 |
# ? Sep 6, 2011 23:02 |
|
OneEightHundred posted:I'm looking at it from a "this costs, at minimum, a third of a junior programmer's yearly salary and will take another month or two to integrate" perspective, which means it should probably be used for more than fade-outs and occasionally moving 2D sprites across the screen. You mentioned UT3 and Bad Company 2; for AAA games like that, the cost you talk about is really nothing. Compared to the huge productivity gains you get in actually making GUIs when you can use Flash, and there you have the reason why 90% of AAA titles these days use Scaleform (statistics totally made up, but it won't be far off). GUI work is hugely iterative as well, so any productivity gain is multiplied many times. Rolling your own is a horrible alternative. A GUI toolkit is one of the hardest things to get right that I've come across. Look at the open source ones; the usual recommendation people make when picking one is the one that is least likely to make you want to tear your eyes out with an icepick...
|
# ? Sep 7, 2011 05:17 |
|
OneEightHundred posted:I'm looking at it from a "this costs, at minimum, a third of a junior programmer's yearly salary and will take another month or two to integrate" perspective, which means it should probably be used for more than fade-outs and occasionally moving 2D sprites across the screen. It's amazing how bad some studios are with that though. I was on a project that spent 3 months of a Jr developers time implementing a sound system that had lots of bugs. Cost to license Miles for that title? 2 weeks of the Jr developers time. Take another 2 weeks to implement it and it wouldn't have had anywhere near the bugs we lived/shipped with.
|
# ? Sep 7, 2011 14:58 |
|
Um the reason why a lot of studios implement Scaleform for minor implementations is just because they're anticipating using it in another product or they sell their engine as middleware and having support for it is very important. I mean UT3 meant implementation for UE and BC2 meant implementation for Frostbite, if any company is licensing any of the engines with it implemented then it's incredibly easy for them to use at considerably less cost than rolling their own.
|
# ? Sep 7, 2011 15:19 |
|
Vinterstum posted:You mentioned UT3 and Bad Company 2; for AAA games like that, the cost you talk about is really nothing. quote:Rolling your own is a horrible alternative. A GUI toolkit is one of the hardest things to get right that I've come across. Look at the open source ones; the usual recommendation people make when picking one is the one that is least likely to make you want to tear your eyes out with an icepick... The reason there aren't many of them is because, as mentioned, it isn't hard. I can get hard when you need scissored windows, frames, and layout automation, but a shitload of games don't even do that, they just plop 2D controls at fixed locations and that's it. I had a mostly-functional UI framework that DID do most of those things on a previous piece of work and it probably took less than a month. If I wanted to add two-state transitions and sine interpolators then that would probably take a whole day. brian posted:Um the reason why a lot of studios implement Scaleform for minor implementations is just because they're anticipating using it in another product or they sell their engine as middleware and having support for it is very important. I mean UT3 meant implementation for UE and BC2 meant implementation for Frostbite, if any company is licensing any of the engines with it implemented then it's incredibly easy for them to use at considerably less cost than rolling their own. OneEightHundred fucked around with this message at 15:41 on Sep 7, 2011 |
# ? Sep 7, 2011 15:38 |
|
OneEightHundred posted:They still don't throw money at useless middleware just 'cause, and 5 figures for 2001-era UI design is an odd trade. 5 figures really isn't that much compared to an engineer's time, or especially the lost time and content thrash of artists/designers fighting with bad tools. We exposed CEGUI (Crazy Eddie's GUI) in Idyllon, back in the day, and it was a reasonable open-source simple GUI option. I wouldn't do that again, and it made sense only because we had time but no budget for licensing.
|
# ? Sep 7, 2011 15:46 |
|
Shalinor posted:5 figures really isn't that much compared to an engineer's time, or especially the lost time and content thrash of artists/designers fighting with bad tools. This is the real answer. Programmer time is rarely the limiting factor for a content feature -- more often than not, every hour a programmer spends developing or integrating a technology corresponds to five or ten hours of content working with that tech.
|
# ? Sep 7, 2011 16:53 |
|
OneEightHundred posted:Usually the licenses for middleware are per-title. And? The point is the cost and man power of implementing it, when a company is licensing an engine and wants to use Scaleform they don't want to have to spend the extra money implementing it, especially if they're on limited source access licensing deals. Also usually is a really weird term to use in this case since whether middleware is included in the licensing or is licensed separately varies heavily from engine to engine and from specific middleware within those engines. Obvious examples being Havok in UE is integral and included, while scaleform or some special lightmapper like Beast may not be as it's not necessarily needed.
|
# ? Sep 7, 2011 17:33 |
|
|
# ? May 13, 2024 11:20 |
|
Oh god look what I started I'm sorry I'm sorry don't hurt me
|
# ? Sep 7, 2011 21:49 |