Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5309394 GameObject class doesn't draw a image but a white box instead

Posted by on 04 September 2016 - 09:59 AM

Not sure what you mean by "school-example type of inheritance", what's the difference between that and "good" inheritance?

 

In school they teach you things like "a triangle is-a shape" and a "car is-a vehicle." They are examples that are simple to grasp, but in practice they are problematic. A game object should almost certainly not be a sprite, in whole or in part. That implies a lot of things that are extremely inflexible: all game objects are visible sprites with position, no game object can have more than one associated sprite, et cetera.

 

As for your actual problem, you're not providing enough information to say. You should most more of the code. In particular it's unclear where all of your members are initialized and to what, and as another poster commented above, that's likely the culprit.




#5309389 Hostility in the field

Posted by on 04 September 2016 - 09:44 AM

Must it be infinite? Do you actually expect an applicant to tolerate any roadblock, spend any amount of resources to get a game programming job?

 

That's obviously not possible. It is true that you can take an expectation of "passion" to an extreme (that is, use "we want you to be passionate about game" to mean "we will work you overtime for months without compensation") that is unhealthy. It happens. Just like other bad things happen in the industry. But that doesn't mean that everybody does it. For most people having a desire to work in the industry is simply another one of the many positive aspects of a candidate that they look for when recruiting. It does not need to be a "requirement," just like a degree is not a "requirement" and you can get jobs without it. It is certainly a plus in the favor of the candidate, though, if he or she can demonstrate that they really enjoy and want to make games as a career.

 

After reading all of this, I am starting to wonder less if either of us are cut out for this field, and wonder more if this field is cut out for us. I still have the freedom of choice - thank providence; my young acquaintance is broke, hungry, and on his last month's rent. I can't possibly see how he can switch careers now unless there is one that requires exactly the same skills as a game developer demands - and even then, he won't have the experience of the field that those employers demand. You're watching one of your own (though it's obvious you don't feel any kinship) lose life's struggle and I see no ounce of remorse. I fear that next month I may find him on the sidewalk either begging for change - or worse, heaven forbid - lying in a pool of his own blood under a tall building.

 

I'm a little unclear at this point what the aim of this thread is; I feel like we have wandered off on a slight tangent.

 

What sort of answers are you looking for at this point, and to what questions?




#5309299 Hostility in the field

Posted by on 03 September 2016 - 08:41 AM

"

"People who are slow and methodical may work well in other jobs, but tend not do well in software";

 

Being slow and methodical can be fine, but it is also correlated with not being particular agile. In software development, especially in games development, there can be a lot of sudden shifts in the direction of one's tasks due to various changing requirements. Maybe some system reached a prototype stage and was determined to be really boring and needs to be cut or reworked. Maybe you do need a demo for E3 even though your publisher said last week that you didn't. Maybe the system you checked in four days ago and which you've now moved on from has a sudden, mission-critical bug and you need to drop everything to fix it. 

 

If weathering those sudden randomizations of your task list is difficult for somebody, that somebody may find it more frustrating than they'd like working in games.

 

Second, you mention passion - a lot. I've never seen the word passion mentioned that many times in a safe-for-work context.

 

Most of the time when reasonable people say refer to a "passion" for working in the industry they just mean "do you want to work in the industry?" (As opposed to "are you just in this for the money/benefits/whatever?) Most reasonable people, at least. Frob is a reasonable person, so I would not let the term scare you off.




#5309221 Understanding Visual Studio's Profiling

Posted by on 02 September 2016 - 02:55 PM

What is it you're trying to do?

 

If it's just understand the heap usage of your code, you should be done at this point. You're seeing heap usage from third-party code, as far as we're currently able to determine, and there's nothing you can do about that unless you want to go in there and muddle around in their code. Compiling things in a different compiler and looking at it in a different will likely change the perception of usage because either different tools will track different things or the same tool will not be able ot track certain things that the different compiler annotated differently, et cetera.




#5309205 Hostility in the field

Posted by on 02 September 2016 - 12:49 PM

Is this industry really that hostile? This seems a bit extreme to me.

 

 

Not at all. I would not worry about the hostility displayed by a handful of people on the internet; those people are not a good, representative sample of people actually working in the industry, most of whom are quite excellent.

 

As an aside, if that quote was from this message board, please flag the actual post or PM me a concrete link to it.




#5309042 Understanding Visual Studio's Profiling

Posted by on 01 September 2016 - 01:33 PM

What kind of allocation it is reported as? Well, the profiler does not say this. It only shows a graph and the current RAM used. I cannot find in the heap profiler.

 

Yes. There are differences between, for example, memory reserved by the OS for your process and actually committed for use, and differences between memory actually requested for your use by malloc/new/et cetera and what actually needs to be reserved. Chances are you're not seeing anything complex with reservations if you're just looking at the heap graph.

 

It pretty much is the sf::RenderWindow that allocates 68mb.

 

Once again, you need to look into what the code in question actually does. There are no heap allocations on the line where the "Allocation Test" window is instantiated; it's on the stack. Therefore the source of the heap allocations must be inside the RenderWindow constructor.

 

Is it possible Visual Studio's compiler bloats this?

 

No.

 

If you look at what constructing a RenderWindow does, it simply calls a base-class create function that comes from Window. This function creates the private OS-specific window implementation as well as the OpenGL context, it also calls RenderWindow's 'onCreate' which will initialize the render target for the window. There's quite a few heap allocations in there, including the backing store for the render target and so on.




#5308881 Understanding Visual Studio's Profiling

Posted by on 31 August 2016 - 11:38 AM

I have no OS calls, if that would matter in any way.

 

Maybe you don't make them directly, but almost certainly things you call make them (for example, anything that allocates memory or reads from a file). 




#5308552 the dreaded "escort" quest

Posted by on 29 August 2016 - 03:13 PM

hmm....   un-fail-able quests aren't much of a challenge... 

 

Yes, but keep in mind that Guild Wars 2 is an MMO and the things in questions are in-world events, not "quests" in the traditional sense. They were design to be things you do as you wander the world, but not things you actively engage in the way you might a quest that was specifically given to you. Also they have to contend with anti-griefing, which is not a problem in a single-player game, and also some events do "fail" and chain into follow-ups. Also keep in mind that winning is not the same as not-failing. You can, for example, scale rewards accordingly in order to incentivize players to actually try, or to create a reason for there to be a challenge.

 

If your game is single-player, I'm not sure it's particularly worthwhile to look at the details of the gameplay ramifications of a massively-multiplayer game. Sure, look at the broad strokes, but be careful of the nitty-gritty details because the considerations are quite different once you have hundreds and hundreds of players with potentially competing interests.




#5308544 win10: no native support for pre-dx10 games. additional runtime required?

Posted by on 29 August 2016 - 02:29 PM

That's not necessarily true, as there are many different versions of the D3DX runtimes that do not sync up with the D3D runtimes. Just because you have versions 1, 3, 8, and 15 doesn't help if your game needs version 11. 




#5308535 Where do I go from here?

Posted by on 29 August 2016 - 01:35 PM

Do I not have enough experience? Is it next to impossible to hire a junior  game developer from another country?

 

It's a difficult value proposition for a potential employer, unfortunately. Bringing in an employee from another country often means some combination of going through government hoops to get a visa, providing a bunch of documentation that nobody local could do the job, and paying money (both in process, fees, and in relocating you). In the case of junior positions, there are usually plenty of interested and qualified candidates to fill such a position locally, and you yourself aren't bringing a ton of seasoning and experience to the table, so it's not nearly as common to hire juniors on visas as it would be to hire seniors. Indeed, junior people are often a net productivity loss initially, with the expectation that after they are trained and molded they will pay off as an investment. But the risk on that investment is much higher when you factor in the higher buy-in costs associated with international hires.

 

I don't think your experience is an issue. I think you probably have plenty to get hired as a junior developer. 




#5308491 win10: no native support for pre-dx10 games. additional runtime required?

Posted by on 29 August 2016 - 09:46 AM

d3dx9_43.dll
 

 

As above, this is not a D3D DLL. It's a D3DX DLL (note the bolded "x"). You've always needed to bundle the redistributable installer for this (not the actual DLLs, that's not legal). Chances are you may have no noticed it before because you picked up a version that some other game or program installed as part of its installation process.




#5308490 the dreaded "escort" quest

Posted by on 29 August 2016 - 09:44 AM

Everything you're talking about there are minor mechanical tweaks. They can help (especially as some of them imply broader gameplay choices that can be re-used elsewhere), but you might instead want to think about something more broad and more outside the box. For example, what if the players are being escorted (and NPCs are defending them from significantly higher-level foes) for some reason? Depending on the context and the method of storytelling you're using, this can offer a significantly different perspective on the quest to the player while still fundamentally being the same thing, code-wise.




#5308119 trek game

Posted by on 26 August 2016 - 05:03 PM

"Making money off of" something is not what causes it to be copyright infringement though.


#5308080 trek game

Posted by on 26 August 2016 - 12:56 PM

If phil makes a star trek game that causes paramount to come after them I'll eat my shoe.

 

Likelyhood or unlikelyhood has, unfortunately, nothing to do with legality.

 

Plus now I'm tempted to tip them off just to see you eat a shoe. 




#5307638 Game architecture

Posted by on 24 August 2016 - 09:25 AM

But i need to tell each tile what it is and what is its texture and parameters. where should i put it and what a good way to do it ?

 

The simple way is to do:

struct Tile {
   Texture * texture;
   .. etc ..
};

This gives each tile a texture and other parameters related to rendering. It's simple, it's easy, and it works. It will probably be perfectly fine for you for now.

 

The big disadvantage is has is that it couples logical state (the tile) with rendering state (the texture). This, by the way, is why it's nice to have explicit dependencies. You can see that the tile depends on the texture to function. If this seems ugly, good. It sort of is, and making the dependency explicit makes it very obvious that it's ugly so that it gets in your face until you fix it.

 

The slightly-more-advanced solution is to give tiles in your tile map a type, which is just a logical identifier, perhaps an enumeration value that says if the tile is a floor, wall, et cetera.

struct Tile {
  TileType type;
  .. etc ..
};

Your map is a collection of Tile objects, when it's time to render the tiles you look at each tile you're about to render and decide based on the type which texture to draw (perhaps also based on a tile set, that is, a dungeon tileset versus a city tileset). This divorces the tile and the texture, the former no longer depends directly on the latter. Instead, the relationship between the two is understood by something at a higher level of abstraction that both tile and texture, one that already understands that both exist.






PARTNERS