Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

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

Posted by on Yesterday, 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 Yesterday, 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 Yesterday, 09:46 AM



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.

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

#5307412 Game architecture

Posted by on 23 August 2016 - 09:16 AM

You can, it's not a great idea though, because it's letting you get sloppy and not think about the impact taking the dependency on the resource loading system actually has on the rest of your code.

#5307275 My College Dilemma

Posted by on 22 August 2016 - 03:45 PM

Is there anything else you're interested in studying?


I normally would not advise a "game design" degree, because in general I think those programs aren't worth the money; generally the programs seem extremely shallow or overly topical (that is, focusing on trends).


 A computer science degree is a good course of action for aspiring game programmers. It's not necessarily a good idea for somebody who isn't interested in computer science (which is not "programming"). Consequently if you're looking at the degree because you think it might be "better" for your career but aren't actually interested in the actual subject matter... I would recommend against it, and instead suggest you take the game design degree program or some other course of study related to things you are actually interested in studying.

#5307210 C++ Librarys - When to use .lib vs including .h/.cpp

Posted by on 22 August 2016 - 09:44 AM

Distributing reusable code as a library is usually advantageous because


  • it is fewer files for the consumer to wrangle (just one library file and one header at the minimum)
  • it is faster to compile, because it's already compiled, so the consumer's compiler does not need to recompile it ever
  • it means you are not exposing your source code directly, which is advantageous if you don't want consumers to have direct access to the code for whatever reason

Naturally you can eliminate these advantages if you handle the building and distribution of the library poorly (such as not collapsing your public headers to as few files as possible), and some of these advantages may not matter to you (maybe your project is open source, so keeping the code private is not a concern). Yes, consumers do need to configure library and header search paths, but that's generally assumed to be a basic cost-of-doing-business and isn't really that much harder than adding multiple external source files to a project.



Just distributing the source directly means you don't have to deal with all the various build configurations needed to ship the appropriate variants of the library for all supported platforms, so that's more advantageous to you. However you are sometimes taking that savings at the expense of advantages for the user (or at least, at the cost of creating potential disadvantages). For example, if your code doesn't compile cleanly on a client's machine because they used a stricter warning level, that's now something they have to manage or work around themselves.


Generally I find source-only distribution to be worthwhile if you have a single-header or maybe a single-header/single-source pair. But generally if there's more than one file involved, or any source files, I'd prefer a library and will usually build such source-only projects into a library myself before linking them with any of my projects.

#5307038 How to use Swift(Xcode) to write the slither.io?

Posted by on 21 August 2016 - 11:14 AM

That seems, as I said in your StackExchange post, reasonable, although I wouldn't worry about implementing the Tiled map and importing it until you get the basics of the gameplay down in a simple, hard-coded box level or something. You may want to look into Apple's SpriteKit library, which can help you with the basics of getting sprites up and running and all that.

#5306908 Engine design v0.3, classes and systems. thoughts?

Posted by on 20 August 2016 - 01:27 PM

Play nice, please. And stay on-topic.

#5306839 Some problems with ECS design

Posted by on 19 August 2016 - 09:53 PM

What if someone want to remove component inside for_each? How to fix this bug?



Accumulate any objects that should be destroyed in a separate list. Once you've done the primary loop over the objects, delete everything in the list and discard it (essentially, defer actual deletion until the end of the frame). 

#5306261 Engine design v0.3, classes and systems. thoughts?

Posted by on 16 August 2016 - 06:20 PM

It's a pretty picture, but at the level-of-detail you've shown it looks basically like any other generic engine high-level architecture.

#5306079 Is it pathetic to never get actually helpful answers here?

Posted by on 15 August 2016 - 10:00 PM

So if I decide to leave the forum, how can I do it?



Nothing special, just stop coming to the website. 

#5305498 List of Smart Pointers to Objects

Posted by on 12 August 2016 - 10:38 AM

So it would be bad if the state wants to delete itself?


Depends. If you're talking about "delete this;" than that is almost certainly a bad idea. If you're talking about knowing that the state has completed its work and should become inactive permanently, that's another thing altogether. You already have a system by which a state can make itself active or not; this sets a flag which the owner of the state queries when doing updates. If you want to support "permanent deactivation," you can simply create a similar flag and have the owner collect all states that marked themselves as permanently deactivated during an update and delete them itself.


Personally it seems like a weird thing for a state to do, but maybe it makes more sense in the context of your specific implementations. 



For example, the state has its own key-events. Now, a key has been pressed that will create a new state. The old state is now pointless.



This makes a little more sense; this is just transitioning to a new state, which you can also communicate via some flags or calls to the owner. You may not actually want to destroy the original state here (what if the user wants to come back to it and see everything in the same spot?) though.

#5305490 List of Smart Pointers to Objects

Posted by on 12 August 2016 - 09:58 AM

So it is completely legit to have this authoritative owner which controls lifetime?


Yes, and it's usually good. Having clear rules and conventions about who owns what leads to fewer bugs, generally speaking, and easier-to-reason-about interfaces.