Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

FlyingDodo: Jan 22, 2005; Not Extinct

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.

On the one hand, I'm relieved that it's finally fixed, but on the other hand I'm pissed off that it took this long to figure it all out. Some of the documentation for the newer OpenGL stuff is absolute garbage. The docs for glDrawElements say the last parameter is supposed to be a pointer to your array of indices, but of course what it ACTUALLY wants is an offset into the buffer you already set. Not that I could find any mention of that until I stumbled across it in a tutorial on some random guy's website. And none of the tutorials I could find go beyond drawing a single box or triangle or whatever, so how VAOs and VBOs are supposed to be set up for multiple objects is a loving mystery unless you can find someone who's been through this mess already to tell you.

Take your pick. gently caress.

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

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 18:13

Vino: Aug 11, 2010

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

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

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. :zombie:

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

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

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

Vino: Aug 11, 2010

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

Physical: Sep 26, 2007; by T. Finninho

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

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

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

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

Physical posted:

What are VBOs/VBAs?

Vertex Buffer Objects and Vertex Buffer Arrays. Take all you vertices and arrange them sequentially in memory. To turn them into a VBO/VBA, you have the mark them off to OpenGL, which a lot of people call "compiling." It's not really compiling in the sense of programming or anything; I speculate it's a leftover from display lists. Anyways, once compiled, it'll try to ram it down into the video card's memory--assume it has the memory for it. Now you can work with the vertices much closer to the video card's hardware itself, without having to beam all the same vertices over and over across the bus. You'll improve your performance right there. The downside is you put a bunch of traffic cones around the vertices when you compile it. You can't just casually go in and muck with a vertex anymore. But so long as you can manipulate them using stuff resident to the video card like viewing matrix transformations or vertex shaders, then you're fine.

# ? Sep 3, 2011 16:18

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

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:

glBufferData(NULL, bufferSize)  // Signals that the current contents of the buffer will not be used
glMapBuffer                     // New memory region if the old one is in use
<Copy/process data into memory returned from MapBuffer>
glUnmapBuffer
...
glDrawElements

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!

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

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

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

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

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.

Irony is I'm in pretty much the same scenario, I owe almost everything to a few people much better at this than I am (mainly Forest Hale). Pass it on, I guess.

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

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

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

Your Computer: Oct 3, 2008; Grimey Drawer

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 :saddowns:

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

DrMelon: Oct 9, 2010; You can find me in the produce aisle of the hospital.

Your Computer posted:

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..

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

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

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:

class SoundSystem
{
    // The SoundSystem singleton stuff:
    private static SoundSystem _SoundsSystemInstance = null;

    public static void StartupSoundSystem()
    {
         _SoundSystemInstance = new SoundSystem();
         _SoundSystemInstance.DoStartup();
    }

    public static SoundSystem GetTheSoundSystem()
    {
         return _SoundSystemInstance;
    }

 
    // Stuff the actual SoundSystem does:
    void DoStartup()
    {
        // startup stuff
    }

    void PlaySound( string MySound )
    {
        // sound playing stuff
    }
}

So anywhere that uses the sound system would just do SoundSystem.GetTheSoundSystem().PlaySound("Happy.wav") or whatever.

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

Physical: Sep 26, 2007; by T. Finninho

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.

Typical C-like singleton pattern pseudocode might look like this:
code:
class SoundSystem
{
    // The SoundSystem singleton stuff:
    private static SoundSystem _SoundsSystemInstance = null;

    public static void StartupSoundSystem()
    {
         _SoundSystemInstance = new SoundSystem();
         _SoundSystemInstance.DoStartup();
    }

    public static SoundSystem GetTheSoundSystem()
    {
         return _SoundSystemInstance;
    }

 
    // Stuff the actual SoundSystem does:
    void DoStartup()
    {
        // startup stuff
    }

    void PlaySound( string MySound )
    {
        // sound playing stuff
    }
}
So anywhere that uses the sound system would just do SoundSystem.GetTheSoundSystem().PlaySound("Happy.wav") or whatever.

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.

Thanks man I learned how to be a better programmer from that. But why is _SoundsSystemInstance static? Doesn't that mean it can't be asigned any value except for its initialization ( _SoundsSystemInstance = null)

# ? Sep 6, 2011 00:04

Vino: Aug 11, 2010

"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

Physical: Sep 26, 2007; by T. Finninho

Vino posted:

"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.

Oh yea, const and static aren't the same thing.

# ? Sep 6, 2011 00:42

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

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

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

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

Paniolo: Oct 9, 2007; Heads will roll.

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

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Paniolo posted:

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.

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

Paniolo: Oct 9, 2007; Heads will roll.

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

Your Computer: Oct 3, 2008; Grimey Drawer

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.

Typical C-like singleton pattern pseudocode might look like this:
code:
*snip*
So anywhere that uses the sound system would just do SoundSystem.GetTheSoundSystem().PlaySound("Happy.wav") or whatever.

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.

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

Unormal: Nov 16, 2004; Mod sass? This evening?! But the cakes aren't ready! THE CAKES!; Fun Shoe

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

Paniolo: Oct 9, 2007; Heads will roll.

Unormal posted:

Pros: Your software works in a simple, understandable way.
Cons: Purist dummies will badmouth your practice.

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

Orzo: Sep 3, 2004; IT! IT is confusing! Say your goddamn pronouns!

Unormal posted:

Pros: Your software works in a simple, understandable way.
Cons: Purist dummies will badmouth your practice.

It is actually quite possible to write simple, understandable code without using a pattern which is essentially a glorified global variable.

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

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

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.

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)

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

Vino: Aug 11, 2010

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

Rocko Bonaparte: Mar 12, 2002; Every day is Friday!

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

Paniolo: Oct 9, 2007; Heads will roll.

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

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

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.

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.

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

Vinterstum: Jul 30, 2003

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.

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.

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

Hughlander: May 11, 2005

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

brian: Sep 11, 2001; I obtained this title through beard tax.

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

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Vinterstum posted:

You mentioned UT3 and Bad Company 2; for AAA games like that, the cost you talk about is really nothing.

They still don't throw money at useless middleware just 'cause, and 5 figures for 2001-era UI design is an odd trade.

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...

Gtk/Qt/Wx are not meant for what you'd normally call a "game UI" and most of the premade ones have the main fault of not integrating with the engine material system.

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.

Usually the licenses for middleware are per-title.

OneEightHundred fucked around with this message at 15:41 on Sep 7, 2011

# ? Sep 7, 2011 15:38

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

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.

It would still cost more to implement a custom simple GUI system, test it fully, create a tool system that makes it reasonable to use, test the tool, and train usage of the tool.

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

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

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

brian: Sep 11, 2001; I obtained this title through beard tax.

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

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 18:13

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Oh god look what I started I'm sorry I'm sorry don't hurt me :ohdear:

# ? Sep 7, 2011 21:49

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »