Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Yesterday, 10:53 PM

#5289288 getting fired in software industry

Posted by Josh Petrie on 29 April 2016 - 12:59 PM

 I was fired from the last position because I think

 

 

It doesn't really matter why you think you were fired, it matters why you were actually fired. Why was that? Were you told? How was your termination communicated to you?

 

 

I have no other career opportunity

 

 

This seems unlikely.

 

Should I quit software development ? am I that bad ?

 

 

This is not a question we can answer for you. If it doesn't make you happy, maybe stop doing it. If it does make you happy, keep trying.




#5289264 Lol, IDirectDrawSurface7::Blt changes Aero scheme to Windows 7 Basic

Posted by Josh Petrie on 29 April 2016 - 10:52 AM

DirectDraw 7.0

 

 

...you know this has been deprecated for years, right? So the fact that it misbehaves on modern systems should not be that surprising.




#5289174 (flower blooming) done...code inside

Posted by Josh Petrie on 28 April 2016 - 07:12 PM

Let's not necro posts from 2007, okay?




#5289096 C++ CLI or native for game engine

Posted by Josh Petrie on 28 April 2016 - 09:35 AM

In many games there are VC-Runtime executables

 

 

Most applications dynamically link to the VC++ runtime. Yours should too. This does not mean they are C++/CLI executables; they're usually plain C++ executables, but (functionally) all C++ executables require linking (dynamically or statically) to a C++ runtime.

 

"Visual C++" is a slightly inaccurate name for Microsoft's Visual Studio IDE. It's a tool not a language. C++/CLI is a language that was mainly useful for writing libraries to interoperate between C# and C++. You should definitely not use it to write your game.




#5288786 Returning by value is inevitable?

Posted by Josh Petrie on 26 April 2016 - 12:13 PM

Also, any function returning a reference should almost always guarantee that reference is safe to hold without requiring the reference return be immediately copied (otherwise, just return by value).

 

With your example, one cannot write: result_type & a = SomeFunction(); and expect it to work reliably. Any subsequent call to SomeFunction, including one on another thread, will overwrite the static variable named by a.




#5288782 Is two people enough for a team?

Posted by Josh Petrie on 26 April 2016 - 12:04 PM

Many thanks for your advise. On my resume, could I still mention a team of 2 developers? or would it be best not to mention how many people, given how small the team is?

 

 

 
Sure, it won't hurt to mention the team size. Generally you should focus on listing things that are interesting, cool or exciting about a project on your resume, but it's pretty easy to mention team size or at least the fact that it was more than just you in there.



#5288776 Is two people enough for a team?

Posted by Josh Petrie on 26 April 2016 - 11:28 AM

Would an employer ridicule the idea of 2 people as a legitimate team work?

 

 

Nobody is likely to care that much one way or another, really, I wouldn't worry about it. Certainly don't add another person just because you think it would demonstrate some team management or interaction skill better (the only thing it demonstrates to me is that you don't know how to run a team at all, because you're adding people for the sake of adding people).




#5288212 Should you load assets/resources at runtime or compiletime?

Posted by Josh Petrie on 22 April 2016 - 05:15 PM

For small games I'd recommend embedding it into the executable because it allows a smaller package.

 

 

 
A resource doesn't magically shrink because you embed it into an executable.



#5287984 Should you load assets/resources at runtime or compiletime?

Posted by Josh Petrie on 21 April 2016 - 09:27 AM

I was trying to show that loading into a .dll is pretty trivial with my setup, although I like embedding more.

 

 

Okay, although I don't see what that example really does, as there is no DLL there and there's also no real embedded there. It looks like a bunch of overcomplex macros to fill out an enumeration. Unless your postprocessing that further or something?

 

By the way, a big reason for asking this question was to find out why so many games embeds pretty much no data into the executable, while it doesn't seem to have any disadvantages.

 

 
Well, the answer to that is because there are disadvantages, as hopefully we've illustrated by now. There are a handful of small advantages to embedding, but in general they don't outweigh the disadvantages or the advantages you gain from a more flexible runtime-loading approach.

 

 

 

I disagree just a little with what Josh and Frob have said: Embedding your assets into the executable makes for an awful time in adjusting them without a rebuild and without technically oriented developer-centric tools like resource editors. 

 

Er, but that's basically what I said?




#5287866 Should you load assets/resources at runtime or compiletime?

Posted by Josh Petrie on 20 April 2016 - 05:52 PM

I'm not sure what you're trying to convey there? Is that supposed to be an explanation of why (you think) this is faster? Or is it simply informational/posted for further critique or advice? If the former, it doesn't address the above points regarding the performance of embedded resources.


#5287712 Should you load assets/resources at runtime or compiletime?

Posted by Josh Petrie on 19 April 2016 - 08:38 PM

If you wanted to go nuts with building assets into executables instead of reading files, you could put them in DLLs. Then you can load and unload the assets and the code that goes along with them at run time. Each level could have its own DLL. However, I must say, this is probably a bad idea.

 

 

Putting stuff -- assets and code -- into DLLs for hot-reload purposes is still a pretty valid technique. Unreal supports it (for code, but you could force it into working for assets). It can be rather a pain to get done right, though, and if you're talking about doing it for assets only it's probably way more work in the long run than just implementing a more vanilla approach for hot-reloaded assets from files on disk.




#5287653 Should you load assets/resources at runtime or compiletime?

Posted by Josh Petrie on 19 April 2016 - 02:11 PM

It's a trade-off. You should probably do both, depending on the purpose of the asset.

 

"Compile-time" loading, that is, embedding the resource into the executable, has the advantage of the resource always being available. There's no (reasonable) way for the asset to "not be there," so it's a good thing to use for very important, low-level assets, such as your default shaders, fallback "object not found" models and materials, et cetera. However, every resource you embed this way bloats the size of your executable, and they're hard to change or update, so you should use them sparingly and only for things that are very important.

 

"Runtime loading" is reading the assets from a file on the disk or elsewhere. These are way easier to update and patch and you can usually control the layout of the file better (or at least with less effort), which is useful for optimizing loading and patching. The downside is that the data can go missing relatively easily, so you have to have fallbacks or error handling in place.

 

Most of your data should probably be loaded at runtime. The advantages in control (and thus in perf) are significant. It's not true that "compile time loaded" data is faster at all. That's basically never the case in practice, especially if you're going to put all your data into the executable like that. It still gets read from the disk and if there's enough of it will get paged in and out just like anything else. Embed only the most critical of resources.

 

Resource loading has two phases: first you acquire a chunk of bytes, and then you parse or interpret them. It's pretty easy to support both runtime and compile-time assets, you just abstract away two different ways of getting that chunk of bytes (from a file, or from a well-known pointer to a chunk of bytes in your data segment). The rest of the resource handling is independent of the process by which the btyes were obtained.




#5287554 What are the different 2D/3D projections used to develop a game?

Posted by Josh Petrie on 18 April 2016 - 06:52 PM

Sounds like you don't really mean "graphics," but specifically what kinds of 3D projections are available (that's what 'isometric' and 'orthogonal' are, types of projections).

 

Why are you looking for this information? What's your goal?




#5287487 "Timer undeclared identifier" Is my compiler drunk? o.o

Posted by Josh Petrie on 18 April 2016 - 11:04 AM

To expand a bit... remember that in C++, the compiler compiles each source file in isolation, and that generally header files are not source files (rather, they are inserted into a source file during preprocessing).

 

Your Timer.cpp probably has "#include "Timer.h" at the top. Nypyren theorizes (and I agree) that Timer.h has an #include for Time.h someplace, and Time.h has an include for Timer.h as you've demonstrated.

 

Thus, when Timer.cpp is preprocessed, it will first insert the contents of Timer.h, and recursively continue preprocessing. This means it will see the newly-inserted include for Time.h, insert than, and recursively continue preprocessing. It will see the include of Timer.h (inserted via Time.h) and attempt to insert it, but you've used include guards so it will just skip the insertion. The modified Time.cpp now contains, in order:

 

The contents of Time.h.

The contents of Timer.h.

The contents of Time.cpp.

 

Since the compiler was prevented from recursively including Timer.h again before Time.h, the code making use of Timer* in Time.h cannot be compiled, because in that source file Timer hasn't been declared yet.

 

You can work around this, as suggested, by removing the include for Timer.h in Time.h and instead using a forward declaration.




#5286711 Help

Posted by Josh Petrie on 13 April 2016 - 11:36 AM

Consider reading the Beginner's Guide to Python, or Python for Non-Programmers.






PARTNERS