Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Online Last Active Today, 02:56 PM

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




#5286690 Just Discovered this about Lua...WTF

Posted by Josh Petrie on 13 April 2016 - 10:28 AM

Honestly, I don't need the Lua lock and unlock methods. The Lua create childthread was all that I needed.

 

 
I think you might be misunderstanding that page... or I'm misunderstanding what you mean. By "lua create childthread" do you mean lua_newthread?
 
You can't call lua_newthread if you don't provide lua_lock and lua_unlock implementations (well you can, but you'll have race conditions because no locking will be performed!). lua_newthreadcalls lua_lock and lua_unlock. Every lua_pushWhatever function calls lua_lock and lua_unlock.
 
Remember Lua's "threads" are not OS threads. lua_newthread is creating a child state.



#5286679 Just Discovered this about Lua...WTF

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

The lua_lock approach? Yeah, it's not great.

 

It basically boils down to: Lua will call the lua_lock() and lua_unlock() macros around stuff it thinks needs a lock. You must re-define those macros to take an appropriate platform-specific lock in your code. This is the "lock before every access" approach to "multihreading" which can very easily result in a system that has many threads all acting serially because only thread gets the lock at a time.

 

 

In my experience, with the same amount of effort, you can devise some alternative method of solving whatever problem you've got that will be far better suited for multithreading, so I'd stop kicking yourself now.




#5285922 Why learn STL library

Posted by Josh Petrie on 08 April 2016 - 04:35 PM

Seeing that even C++ standard committee members refers to (a specific subset of) the C++ standard library as "STL", that historical footnote really no longer needs to be mentioned, IMO.
 
(the specific subset is the algorithm-iterator-container chunk, which I'd guess is 70% or more of the overall standard library)

 

Should people avoid books like these because 'the STL is no longer used'? (edit: okay, bad example, seeing as that book is from 2001. But I hear standard committee members using the term STL in modern conference talks as well)

 

I think denying that usage brings more confusion than permitting it, though obviously many disagree. Especially 20 years later when a beginner isn't likely to accidentally be using the SGI-STL, and anyone using something like STLport is experienced enough to already know the distinction, I think this programmer-war can be laid to rest.

 

The C++ Standard Library is not the original STL. But a large part of the C++ Standard Library has also adopted/co-opted (through general usage) that name.

 

 

I don't really disagree, but given the brevity of the original post, the relative lack of context, and the fact that as you imply there are still plenty of people out there who stubbornly (almost zealously) insist that one should absolutely never use the term "STL" unless one means Stepanov's library only, I wanted to be clear. I wouldn't give the same answer for the original STL as I would for the modern standard library (there's really nothing worth studying in the original STL unless one is a language history buff).




#5285822 Why learn STL library

Posted by Josh Petrie on 08 April 2016 - 09:54 AM

I presume you mean "STL" in the sense of the C++ standard library and not the actual STL that eventually influenced/became the standard C++ library.

 

It's important to know the standard library for your language, and that's just as true with C++ as with anything else. The standard library provides significant useful functionality, defines significant useful paradigms, and is generally a very powerful tool. Without the standard library of a language, there's often very little you can usefully do.

 

It's important to understand the standard library even if you intend to "reinvent" aspects of it, such as its allocator mechanism, its smart pointer library, or its container types. If you don't understand it, at least to some degree, you can very easily end up with inferior home-grown alternatives. It's also important to understand from the perspective of being able to comprehend other code written in the language.




#5285271 Impressive professional/industrial 3D engine

Posted by Josh Petrie on 05 April 2016 - 09:43 AM

This engine clearly took some serious development time and skills to make. And although I know the aviation industry (particularly the military one) involves a lot of money, I still think it's curious how they were able to find the people with the skills to do it.

 

 
I don't mean to downplay the effort that went into developing this, because as you say, it's non-trivial. However, it's also not that impressive. It's a pretty good result, but it doesn't require superstar million-dollar developers. Just some competent engineers and artists, the kind you can find at almost any game development studio.



#5285117 Community College or Game Development?

Posted by Josh Petrie on 04 April 2016 - 04:14 PM

wouldn't it be easier to get into this industry with a 100% completed project rather than any kind of degree?

 

 

Nope. In fact it might be harder.

 

Stay in school, finish your degree. Work on projects on the side. Most of the people you'll be competing with in the job market once you graduate will have done that. They will have interesting hobby projects and a degree. So to stay on par with them, all other things being equal, you'll probably want that degree.

 

Naturally there are exceptions, and it it's certainly possible to get a job in the industry without any sort of relevant degree. Are you willing to make that gamble? There are probably things that will be taught in your degree program that will be hugely useful to your future career, things you don't currently know about, and which you probably don't even know you don't know about. By cutting yourself off from that experience you risk weakening yourself, both as a candidate on paper and as an actual developer doing work on a game.




#5285046 What is the most organised way to create a class/file structure for a game?

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

I generally produce one file for class or type, except in languages like C++ where I generally produce one .h/.cpp (and maybe .inl) tuple.

 

Free functions a grouped into one file (as above) based on functionality (e.g., string-related functions go into one file, hash-computation functions into another file). Small types like enumerations or delegates generally go in the file that they are associated with (window property enumerations would go into the window class file), except in some circumstances where they are useful on their own or to a wide variety of types.




#5284127 N64, 3DO, Atari Jaguar, and PS1 Game Engines

Posted by Josh Petrie on 29 March 2016 - 04:38 PM

Some games of that era had "engines" in the sense that the studios making those games would reuse large portions of the code, tool and processes from a prior game when building a new one, even as far back as the NES.

 

None of those engines are commercial available products. You will need to write your game code from scratch.




#5283298 How can I locate a memory leak?

Posted by Josh Petrie on 24 March 2016 - 07:40 PM

Well that escalated quickly.




#5283175 BitMap Animation (Help needed)

Posted by Josh Petrie on 24 March 2016 - 11:04 AM

And yes bmp has teh ability to animate since i have a bmp animation seen somewhere else alot

 

 

 
No it doesn't. What you saw was somebody implementing an animation using .bmp images (by playing them one at time, themselves). The .bmp file format does not have animation support built-in to its format at all.



#5282895 What game is suitable for a beginner to make (with C++)?

Posted by Josh Petrie on 23 March 2016 - 09:31 AM

Games that don't require "graphics" are generally easier to start with; ones that function will with just text-based input and output. "Guess-the-number," Hangman, Blackjack, text-based adventure games. That sort of thing.

 

If you've built those and feel comfortable, moving to graphical games via some windowing API like SDL or whatever, and then focusing on simple games there like Pong or Asteroids is a good next step. Snake is not a terribly more "advanced" game than either of those though, so if you're otherwise comfortable with everything you've done with the game so far you probably don't need to backtrack to a simpler game.

 

Instead, why don't you try to explain the problem you're having and how you've tried (and failed) to solve it so far? You will always run into these sorts of situations when programming and generally avoiding it and going back to a simpler project isn't going to be helpful (or possible). That doesn't mean you just have to beat your head against a wall when you're stuck though. You can ask for help.




#5282664 Help figuring out Megaman's jump curve - PLEASE!

Posted by Josh Petrie on 22 March 2016 - 10:24 AM

I assume you've seen the information used by tool-assisted speedrunners? http://tasvideos.org/GameResources/NES/Rockman.html and http://tasvideos.org/GameResources/NES/Rockman/Data.html#JumpCurve for example?

 

The actual application of the deltas and rounding are probably just done directly in the code somewhere, it shouldn't matter where or be particularly important as long as you just apply the same rules (e.g., clamp Y speed to -12 when it gets below -12, et cetera).






PARTNERS