next »

[ProgramGamer]

Your quote is broken, you're missing a ] bracket.

Edit, paged this:

[quote author=Dacke link=topic=48407.msg1227300#msg1227300 date=1456878380
A cursory reading on Wikipedia tells me that the registry is a database stored in the system root (similar to /bin, /etc, etc.). So if programs put things in the registry it's stored on a system-level, it's specific to that install.

Which is the complete opposite of storing system settings in user's home folders (i.e. /home/dacke/.somesetting). In which case the setting is unique to that user and gets moved along if the home folder is copied to another install.

The registry is actually a set of databases, one of which is user-account specific (Usually called HKEY_CURRENT_USER). Roaming user profiles will copy the user specific registry DB around like the home directory.
[/quote]

[InfiniteStateMachine]

Do you mean design scope or literally you had issues with too much stuff in global scope?

Design scope? You mean having so many features I can't possibly keep maintaining them all? Ha! I wish. In reality, my game completely fell apart and refused to compile once I moved everything into it's own header. This time around I'm using headers from the start instead of building in main and then moving things to headers.

Ah ok gotcha

[Dacke]

The registry is actually a set of databases, one of which is user-account specific (Usually called HKEY_CURRENT_USER). Roaming user profiles will copy the user specific registry DB around like the home directory.

Oh, ok!

[Cheezmeister]

Hey @Dacke,

Yeah, "databases" is more accurate, I'm not an expert + don't want to get overly academic (without spinning off a new topic). Suffice it to say that:

* There's a rough correlation between hives (HKLM for instance) and partitions (/dev or /etc or whatever)
* HKCU can follow you, the user, around just like $HOME can (but it doesn't mix with your family photos, Unity projects, and porn )
* You can backup and restore reg settings as files almost as easily as dotfiles (like mine for example)!

The upshot is, it's a bit disengenuous to call the registry "BS", just because it's a little weird

[Dacke]

The upshot is, it's a bit disengenuous to call the registry "BS", just because it's a little weird

Heh, yeah, sure. I was being a bit facetious. But there's also the fact that the interactions I've had with the registry (from XP and earlier) have been filled with grief. The weirdness made it feel inaccessible and difficult to fix. But that's just my personal experience  

[anthnich]

With SDL 2.0, what is the best practice for loading textures that can be used throughout the program? What do you guys do? Right now, I load my textures inside a render.cpp like so:

Here's what I do:
(Note: I don't use SDL, so I don't know of the specifics. Also, I use C++.)

I created a Resource class for Textures that contains methods to request/load certain textures. For example, the method will return a Texture when a filename is passed.

Code:

Texture &TextureResource::GetTexture(const std::string &filename);

The class contains a map with a std::string, Texture key/value. GetTexture checks for a key of filename and returns the loaded Texture. If the filename doesn't exist as a key (in turn, the Texture isn't loaded as such), a Texture is loaded from the filename and stored as a value;

Ex Pseudo code.

Code:

Texture &TextureResource::GetTexture(const std::string &filename) {

  if (texturecontainer.count(filename) > 0)
    return *texturecontainer[filename];

  texturecontainer[filename] = new Texture(filename);

  return *texturecontainer[filename];

}

With this, a texture is loaded from the filename and stored in the texturecontainer. Then, everytime that texture is requested later on, it'll pull the one that was loaded. This makes sure there are no duplicate textures.

From here, a pointer/reference to that Resource class is passed to the method/classes/actors that need access to textures.

Ex.

Code:

void TankFighter::Init(TextureResource &tr) {

  m_sprite.loadTexture(tr.GetTexture("sprites/tank.png"));

}

[randomThrowAway]

Should I store my turn based RPG enemies (read: enemy types that spawn all the time, like "grim green grasshopper") as (Java) classes, our outside of the code? Currently I'm storing them in a json file,  reasons being that I like seeing them in one place, can edit / compare quicker, I guess that's meant by readability?

My problem is that I'm now adding different skills and AIs for each enemy and also need a way for them to scale. I can put all this info into the json file, too, but readability goes out of the window with that, fast, so I'm wondering if this approach actually has any advantage, then? Is there any reason for not storing the enemies in ~100 classes? For (development related, not ingame) comparing, I can export those into some table format. Would be an extra step having to open the actual class and edit the enemy there.

I also use a mongo database for other stuff, but I don't think storing the enemy as basically proto classes in there would make much sense as they are for all intends and purposes read-only.

I guess I could also keep the enemies in json and just save a reference to each type's AI as String or whatever, and then have the AI as classes in code? But then I'd end up with nearly as many classes as if I simply put every enemy into its own.

[Vulduin]

Should I store my turn based RPG enemies (read: enemy types that spawn all the time, like "grim green grasshopper") as (Java) classes, our outside of the code? Currently I'm storing them in a json file,  reasons being that I like seeing them in one place, can edit / compare quicker, I guess that's meant by readability?

My problem is that I'm now adding different skills and AIs for each enemy and also need a way for them to scale. I can put all this info into the json file, too, but readability goes out of the window with that, fast, so I'm wondering if this approach actually has any advantage, then? Is there any reason for not storing the enemies in ~100 classes? For (development related, not ingame) comparing, I can export those into some table format. Would be an extra step having to open the actual class and edit the enemy there.

I also use a mongo database for other stuff, but I don't think storing the enemy as basically proto classes in there would make much sense as they are for all intends and purposes read-only.

I guess I could also keep the enemies in json and just save a reference to each type's AI as String or whatever, and then have the AI as classes in code? But then I'd end up with nearly as many classes as if I simply put every enemy into its own.

The way you're doing this with json files seems fine to me for a small scale game but may have performance impacts if you are dynamically creating a lot of complex enemy objects.

Going the json route I would think that you'd want to read in all of the enemy types and create the enemy objects on load, rather than dynamically, because reading from the json file is probably a pretty slow operation. So you would read the json file once on startup and create one of each enemy type, maybe storing it in a map or something where it can be retrieved later.

These instances would be used as a template of sorts to create enemies from later (i.e. a copy constructor). When you want to create an enemy of a certain type, you'd have to get that "template" object and create a new instance of it providing a reference to the template as a parameter to the constructor. The operation of retrieving the enemy type from the map and creating a new instance from that template may be slower that just saying 'new GrimGreenGrasshopper()' to create a new instance which already has all of its properties defined. However, I think this would probably have a negligible impact on performance unless you dynamically create a lot of enemies which are complex objects.

The json route is also more inefficient memory-wise as you'd have to store all of the template objects. But once again, the performance impacts are probably negligible unless you have a large amount of enemy types which require considerable amounts of storage, which I think is unlikely.

[randomThrowAway]

Thanks and yeah, that's basically what I'm doing with json right now; I load it once on startup and store each enemy type in an ObjectMap, then use those to create actual enemies when needed. As long as enemies only differed by variable values (basically numbers and strings) I was reasonably happy, but now enemies need to have different skills (e.g. buffs) and, well I wouldn't call it AI, but decision trees as to what skill to use in a particular situation and especially with those, I don't see them being converted from and to json so easily.

Most straight forward to me would be just storing a string for enemy X which then loads a class enemyXBehavior, but then again when I'm already making a class for each enemy's behavior, why wouldn't I simply make a class for each enemy in the first place?

[Vulduin]

Thanks and yeah, that's basically what I'm doing with json right now; I load it once on startup and store each enemy type in an ObjectMap, then use those to create actual enemies when needed. As long as enemies only differed by variable values (basically numbers and strings) I was reasonably happy, but now enemies need to have different skills (e.g. buffs) and, well I wouldn't call it AI, but decision trees as to what skill to use in a particular situation and especially with those, I don't see them being converted from and to json so easily.

Most straight forward to me would be just storing a string for enemy X which then loads a class enemyXBehavior, but then again when I'm already making a class for each enemy's behavior, why wouldn't I simply make a class for each enemy in the first place?

Yeah I agree with what you're saying and I don't see a whole lot of benefit of doing it the json way. The one real benefit that it gives you is that you could modify enemies' behavior without needing to recompile your code. But once again, this will probably only make a difference if you have a relatively large project that takes time to compile. You could also alleviate this by splitting your code into multiple jars and have your enemy classes in a separate jar to keep the compile time down when fine tuning them. It's something to consider but it sounds like you're leaning towards scrapping the json and I agree that is probably the way to go

[Dacke]

A potential benefit of storing stuff like that in external files is that it makes it easier for others to modify stuff. So if you bring in other people, they can help with fine tuning, testing, maybe enemy design, etc. without having to edit the code.

[randomThrowAway]

Not that anyone cares but I've come around twice; I switched to individual enemy classes for each enemy type, but while building better AIs, I will now return to a JSON list and simply make a couple (I'm guessing 5-10) of AI "Characters" (Brute, Assassin, Defensive etc) and every enemy will have one. Since the list of choices each enemy has at any given time is rather low (~20 at most), I don't need a specifically weighted AI for each enemy.

A cool side effect is that I can assign different AI to a spawned enemy if I want, so I could have in one fight 3 bandits, one of them being defensive, one a maniac and one stubborn, all of them only expressing their character through their limited choice of actions of course.

[Oats]

In the end I just used System.getProperty("user.home") + "/Save Games/Oats/". It's messy and not standardised in anyway but fuck it, if large companies don't have standards I won't either.

Next question, how does OpenGL handle changing colour buffers? I want a bunch of televisions in my game, each displaying a unique animated procedurally generated image, and I'm not sure the best way to do this. Should I give each television it's own colour buffer? Or should I make one that's used by all? The problem is I can't give an upward limit to how many TVs will be on screen at once, so giving each their own seems terribly inefficient, but if I share one amongst hundreds will openGL manage? Does openGL handle a colorbuffer being changed while it may be still in use in the pipeline? Or am I not understanding something? Or is constantly switching buffer a bad way to go anyway, should I try making the screens render all in the main FBO.

[ThemsAllTook]

My intuition says that one FBO per TV would be the most efficient approach to avoid pipeline stalls, but it's hard to know for sure without trying it.

[ProgramGamer]

What is the physics equation used to find the initial speed of an object based on the distance it will travel and its acceleration? I think the final speed of the object is also in there somewhere but in my case it would be zero because my specific case is a jump arc.

Edit: nevermind, I googled it.

[Sik]

What did you find? >_>

[ProgramGamer]

http://www.wikihow.com/Find-Initial-Velocity

[Juskelis]

I'm having a bit of an issue with hexadecimals. Namely, I want to be able to encode two separate values into one byte by using each hex digit as the different values, so that 0x80 would be 8 and 0 respectively. The code I have is fairly simple.

C++ in case it matters

Code:

char encodeInformation(int a, int b)
{
  return (char)(a*16 + b);
}

int decodeB(char toDecode)
{
  return toDecode % 16;
}

int decodeA(char toDecode)
{
  return toDecode / 16;
}

The problem though is that when I decodeA on 0x80, I don't get 8 but instead get 0xfffffff8. Is this just a rounding problem and I have to find some other way to decode this stuff? If so, how do I go about doing this the right way?

[ThemsAllTook]

0x80 as a signed char is a value of -128, so the division and typecast to int on return extends the sign bit. If you used unsigned types, the code would probably do what you expect.

A somewhat more normal way to do these things is with bitwise operators. a << 4 | b for encodeInformation, toDecode & 0xF for decodeB, toDecode >> 4 for decodeA. If you want to guard against out-of-range values, you'll probably want to AND b with 0xF in encodeInformation.

[Juskelis]

So that got it to work! Here's what it looks like in case anyone runs into this 

Code:

unsigned char encodeInformation(unsigned int A, unsigned int B)
{
  return (unsigned char)(A << 4 | (B & 0xF));
}

unsigned int decodeB(unsigned char toDecode)
{
  return toDecode & 0xF;
}

unsigned int decodeA(unsigned char toDecode)
{
  return toDecode >> 4;
}