Game Development Megathread

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

Bizarro Buddha: Feb 11, 2007

http://gpwiki.org/

GPWiki has a bunch of tutorials for all sorts of stuff. They're not the most up-to-date, but they're a starting point.

http://nehe.gamedev.net/

NeHe always gets brought up when people want OpenGL tutorials. I've not actually used them myself, though, so I can't vouch for how good they really are.

I'm just starting to get into OpenGL with SDL myself. I've got an OpenGL book that I'm continually putting off reading.

# ¿ Nov 23, 2007 16:54

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 09:10

Bizarro Buddha: Feb 11, 2007

Vinlaen posted:

I still need a massive 1920x1200x32bit * (amount of screens of terrain) texture though, right? (when using 1920x1200 resolution)

The reason I keep coming back to this is because I'm going to build the visual terrain using many smaller textures, etc. I'm concerned because 1920x1200x24 * 5 screens is a massive amount of texture memory and may not work on older video cards

The point is that if you keep the status of the terrain in main memory and use that to build a set of 2d triangles that consist of what you need to render, you only need a/some small texture(s), because you can repeat them across the triangles you have built.

So you don't need tons of video memory, just enough system memory to store the terrain grid.

# ¿ Mar 3, 2008 12:20

Bizarro Buddha: Feb 11, 2007

In general you don't want a huge amount of GameComponents, so that working out their behaviour with respect to each other is simpler. If you're going to use them, have a GameComponent that manages moving entities, rather than a GameComponent for each moving entity, for example.

Yes, if you want a list of objects you're going to want to make them the same type. Deciding whether to use an interface or a base class to tie them together depends on whether you want to implement default behaviour (easier with a base class) and whether you want to have objects that fit into multiple categories, like an entity which is Drawable and Movable. If you want both, you can take a middle ground by having a base class that implements several interfaces and provides default behaviour for objects that fit into all those categories.

# ¿ Jan 12, 2009 13:55

Bizarro Buddha: Feb 11, 2007

Two things come to mind:

1) What kind are you doing that needs this much nested data? Each object referencing another 3000 objects seems like a hell of a lot.

2) Rather than looking at a speedup by switching to C code you should be looking at using a different data structure with less than linear lookup time. The latter will be a much bigger gain than the former. I couldn't tell you what structure you'd want to use without knowing more about your data, but if it can be ordered then a binary search tree might be a good start. And if your data can be roughly categorised you can use bucketing to cut down on the search space.

# ¿ Dec 22, 2009 08:27

Bizarro Buddha: Feb 11, 2007

Jo posted:

I'm not sure if it's a better idea to have my EntityManager object do all the collision checking or it's a better idea to have the collision checking inside the Entity superclass. Suggestions or advice?

EDIT: First seems more reasonable. Have the entity objects do their updating position-wise, then the entity manager check for collisions.

Bear in mind that updating positions and then checking for intersections will let entities tunnel through things if the timesteps or speeds are large enough.

To be honest for most games I don't think you need to worry about moving things simultaneously, and if you do, those things should be in a real physics system which is going to be complicated to write. For my projects I'm just going to use a pick an update order that makes sense and stick to it, and do continuous collision detection for each entity to make sure there's no tunnelling.

# ¿ Nov 4, 2010 19:56

Bizarro Buddha: Feb 11, 2007

The best way to handle something like this depends partly on what language support you have for various things. Are you working in C#?

# ¿ Jan 14, 2011 16:35

Bizarro Buddha: Feb 11, 2007

Orzo is right that lambdas are a good way to do this. That means that your delegate type will take no arguments, but you dynamically generate new functions to set as delegates on buttons.

code:

// in a class where buttons are created
void Spawn(string type)
{
    state.Add(new Thing(type));
}

b1.Click = () => { Spawn("apple"); };
b2.Click = () => { Spawn("orange"); };

// in the button class
delegate ButtonAction( );
ButtonAction Click;
...
if (mouseOver && clickReleased)
    Click();

# ¿ Jan 14, 2011 20:13

Bizarro Buddha: Feb 11, 2007

What's your actual use case for this interaction system? When it comes to games I'm very wary of writing anything generic especially as a first pass. What are the chances that you're making yourself a hammer before you've realised that you need to deal with screws?

# ¿ Jan 22, 2011 22:16

Bizarro Buddha: Feb 11, 2007

PnP Bios posted:

I'm working on a game engine. (insert rolly eyes here...) but I've already got a few demos working. This system in my case is specifically for object collisions. such as player-bullet, player-switch, etc. The idea being it can be extended to more than just first person shooters. I would say that it's over 90% complete, and am working to implement a game with it. Currently I have about half a dozen sandboxes testing various features.

Sounds reasonable for triggers like switches, though for collisions like bullet-player you'd usually want more information like point of intersection, normal, and so on, which makes your system less generic.

Orzo posted:

People will tell you to write games, not engines. It's an annoying mantra parroted all over the place by people that probably wrote an engine at some time and failed. Do your own thing, writing an engine is a great learning experience which may or may not end up in a successful game.

These people are right. An engine is something that grows out of carrying code over between projects. If you set out to write "an engine" with no game to keep the feature set on track and constantly tested for usefulness, you'll end up with a huge set of systems that are of absolutely no use to you in practice. You should listen to people that tried things and failed, and think about the reasons, rather than calling it an annoying mantra.

# ¿ Jan 22, 2011 23:57

Bizarro Buddha: Feb 11, 2007

PnP Bios posted:

Position and velocity are components of the game objects. I have a different pass for the level geometry.

Slightly nitpicky but position and velocity doesn't give you intersection point and normal without doing work that you probably would already have done in your collision detection, so it doesn't make sense to be forced to redo that work in the handler.

PnP Bios posted:

This isn't a from the ground up engine design. This is the refinement of a series of prototypes. This is the 7th iteration, which I'm going to turn into a full blown game instead of a fancy physics test.

Yeah, this is exactly what I'm talking about. You write the code you need for your prototype, and then you carry the good stuff over to the next one.

# ¿ Jan 23, 2011 00:17

Bizarro Buddha: Feb 11, 2007

I would say use SFML because it's got a more object-oriented design that you'll probably be more comfortable with if you're used to C++ rather than C.

# ¿ Feb 2, 2011 00:35

Bizarro Buddha: Feb 11, 2007

Blender 2.5 is a lot better than 2.4 was, they've completely redone the interface.

# ¿ Mar 4, 2011 17:32

Bizarro Buddha: Feb 11, 2007

Zizzyx posted:

As a personal exercise I'm trying to make an "Active Time Battle" style control structure, to emulate turn-based rpgs. My basic idea was to increment an "energy" variable for each actor during every iteration of the game's main function, and call a function which handles a player's turn when the variable reaches the necessary amount.

Final Fantasy Tactics had a really interesting implementation of this, and included a menu showing you the order in which each unit would take their next turn, as well as when delayed effects would occur. I'd like to emulate this if possible, but I'm not sure how complex of a task it is, so I don't know how to start. Any ideas or examples I could research?

This isn't a particularly hard problem. All you need to do is decide on a notion of time that you're going to work with, then specify all of your gameplay data like action rates and how long a spell takes to cast in terms of that time system.
From that interrogating the time system about when things will happen relative to each other should be easy.

http://roguebasin.roguelikedevelopment.org/index.php?title=Time_Systems - this might be a good place to look if you want some more words to read.

# ¿ May 9, 2011 11:49

Bizarro Buddha: Feb 11, 2007

The Fool posted:

C#/XNA question.

What kind of pitfalls do I need to be aware of if I use Texture2D.FromStream() instead of ContentManager.Load() for loading .png files?

Unless there's a better way to look at a folder that holds an unspecified number of png's and corresponsing xml files, and load them up as whatever sprites the xml file specifies.

edit: XNA 4.0 doesn't have FromFile anymore

I think the only issue is that you won't be able to do that on XBox 360, because you can't access random parts of the filesystem there.

# ¿ Sep 14, 2011 10:45

Bizarro Buddha: Feb 11, 2007

Making no judgements about the sanity of the library you are writing (because it is insane) for the three words to pair with up/right/forward you could try vertical/horizontal/depth. Or just reusing up/right/forward in the context of scaling.

But you are insane.

# ¿ May 8, 2013 17:41

Bizarro Buddha: Feb 11, 2007

The problem is that your order-independent construction of transformations is pretty useless in practice. Things in games very rarely want to move directly in world space. They want to move in their current frame of reference e.g. the way the character is pointing. If you construct a transformation system where things can only move "forward", "left", and "up" then all you're doing is pushing the complexity of deciding how to generate those three values from the actual desired movement onto the API user.

# ¿ May 12, 2013 17:00

Bizarro Buddha: Feb 11, 2007

I think the biggest problem with your testbed being a Doctor Mario clone is that the use of transformations in 2D games is a lot simpler, so you won't be encountering the complexities that might crop up using your library in a 3D context.

# ¿ May 13, 2013 08:32

Bizarro Buddha: Feb 11, 2007

You can eliminate the if statement by using clamp.

e.g. for the white saturation case:

code:

float whiteSat = clamp(hue - 1.0, 0.0, 1.0);
result.r = result.r + (1 - result.r) * whiteSat

I think clamp/min/max will be branchless on pretty much all modern gpus. But as everyone always says, profiling is the key.

# ¿ Oct 3, 2013 21:23

Bizarro Buddha: Feb 11, 2007

Instructions like fsel (and their equivalent in the GPU instruction set) let you put one of two values in a register without inserting pipeline bubbles or dealing with threads diverging.

# ¿ Dec 12, 2013 03:17

Bizarro Buddha: Feb 11, 2007

Shalinor posted:

I kind of take it for granted, since it's Epic, but I assume the Blueprints are extensible with totally custom (C++) nodes?

Also, did it fix the issue Kismet had, where it was difficult to make a single Kismet script, and associate it with an object that's instanced over your entire world without that thing's Kismet hierarchy appearing a billion times in a billion places? Think level design widgets: a single "bulb + switch" or "torch lamp" or "door that opens when clicked" that gets re-used in a billion places, instead of everything being bespoke.

Kismet used to be levels only, blueprint is everything. So you can put blueprint code in a content-only actor class and put instances all over your levels dead easily. Way better than UE3 prefabs. I've even heard of studios completely ignoring level scripting and doing it all with actor blueprints to tie triggers to logic and so on.

As far as custom blueprint nodes - there's two ways you can do things. You can tag any C++ function as callable or implementable in blueprint, and you can put multicast delegate properties on objects that can be registered by blueprints. You can also write extensions to the blueprint compiler that let you place a node in the editor that expands into whatever code you need. This is also how you do things like the old "latent execution" nodes from Kismet. For example a single blueprint node that has an immediate output and another output that fires when a long process has finished. The second way is a quite a bit more involved and I haven't gone through the process myself, but I know we're using it at work.

Above Our Own posted:

Is UE4 primarily component or inheritance based?

I would say primary inheritance even though they have an attempt at a component model. It's not a very coherent attempt and trying to work in a component-focused mentality will give you a lot of pain in my opinion.

This matters less, but performance-wise they are also not set up for a great many components to be used.

Bizarro Buddha fucked around with this message at 01:29 on Aug 5, 2014

# ¿ Aug 5, 2014 01:27

Bizarro Buddha: Feb 11, 2007

Just do it, don't worry about the performance for something like this unless you are doing it hundreds of times a frame and even then you probably don't need to care.

# ¿ Aug 7, 2014 04:30

Bizarro Buddha: Feb 11, 2007

The general way to do that is not to set the camera at a fixed distance but set its goal at a fixed distance from the player, then each frame move from its current location to its goal location with speed and acceleration that feel natural, which involves quite a bit of tweaking.

# ¿ Sep 15, 2014 01:05

Bizarro Buddha: Feb 11, 2007

Corla Plankun posted:

Why do graphics card computation people say "compute" in sentences where it seems like the correct word would be "computation"? The Vulkan site does it a lot so I feel like it is not an accident.

Because when GPGPU stuff was first introduced it was often called "compute shaders" and the name stuck.

# ¿ Apr 13, 2015 04:34

Bizarro Buddha: Feb 11, 2007

Subjunctive posted:

I'm hunting through the engine source trying to trace it, but maybe someone knows: I'd like to synthesize a "fire" event, so that the Character takes the "InputAction Fire" event path, rather than me duplicating that code somehow. I can't see how to trigger that part of the input processing pipeline myself, or even generate a mouse click or key event that I could reverse engineer from the action mappings. I'm more than willing to write C++ for this, but I can't find the code where the mouse click (say) causes a Fire action to be generated and passed through the input pipeline.

The input system is pretty messy and complicated, but if you want to start reading/debugging C++ to understand what's happening I think UPlayerInput::ProcessInputStack is the place to start.

# ¿ May 14, 2015 04:57

Bizarro Buddha: Feb 11, 2007

Shalinor posted:

EDIT: I even had two Epic engineers on Twitter tell me that they don't actually know how the whole .generated.h thing works internally. So that made me feel better.

This does not fill me with confidence but it does not at all surprise me. I recently discovered that if you reduce the number of generated .cpp files a module produces, Unreal's build systems would not delete the out of date ones. That was a surprise.

# ¿ May 20, 2015 06:51

Bizarro Buddha: Feb 11, 2007

Shalinor posted:

The hot reloading is also... special... and you often need to close and re-open UE when you change the public members of a class. It gets reeaalllly confused sometimes. Does it delete the excess generated .cpp's if you close and reopen a few times, maybe?

UE4 is definitely one of those "use GIT, commit often, be prepared to reset" engines. It may actually make sense to do a reset --HARD every once and a while, to force it to regenerate and kick the cruft out.

Nah the program that generates the headers just never checked the contents of the intermediate directory to see if it needs to clear the crufty cpps. I submitted the fix, I think they'll have integrated it for 4.8.

I personally never use the hot reloading at all, I've just never trusted the idea. I'd rather have longer load times than weird heisenbugs.

# ¿ May 21, 2015 18:01

Bizarro Buddha: Feb 11, 2007

List<T> in C# is not a linked list, it's basically an array. It's poorly named.

Edit: ^ :argh:

# ¿ Sep 28, 2015 06:40

Adbot: ADBOT LOVES YOU

# ¿ Apr 26, 2024 09:10

Bizarro Buddha: Feb 11, 2007

But in the places you have control over the code, you could just call a different method with a different name...

# ¿ Nov 18, 2015 07:29

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