Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 05 Aug 2010
Offline Last Active Jul 13 2016 07:37 AM

#5040088 Can't decide which math/physics basics book to get

Posted by on 06 March 2013 - 01:11 PM

Thanks for all the advice, I've pondered quite a bit on this.


I've decided to get Mathematics and Physics for Programmers now. It covers a lot of ground I'm already familiar with, but it really seems like a comprehensive reference of all the basics, explaining them much better than Wikipedia (which I usually turn to for refreshers). And it really covers a lot of ground, from what I've seen pointing to more advanced books for further reading. But it does seem to cover all the things I really need right now.

#5038975 Can't decide which math/physics basics book to get

Posted by on 04 March 2013 - 02:47 AM

It was on your list? You mention 2 books in your post. That wasn't one of them.


On my list before I narrowed it down, is what I meant smile.png But sounds good, didn't notice it covers collision response. And the other books don't allocate many more pages to that anyway. It's definitely on my list now. And since it's apparently quite famous, it's a good candidate, too.


I got good use from Mathematics and Physics for Programmers, Mathematics for 3D Game Programming and Computer Graphics, Game Physics Engine Development, and Real-Time Collision Detection.


You have both Mathematics and Physics for Programmers and Mathematics for 3D Game Programming and Computer Graphics? I havent read the former (obviously), would you say its too basic for someone with a CS degree? Or is it still something you refer back to occasionally?

#5038952 Can't decide which math/physics basics book to get

Posted by on 04 March 2013 - 01:14 AM

Mathematics for 3D Game Programming and Computer Graphics is not on your list, but I own it and think it's excellent. It has chapters on everything from simple topics to advanced, and will function as permanent reference material when you are done reading it.


It was in fact on my list, but I thought it didn't cover physics. Just saw that it does. Would you say that it manages to bring across the basics well? It's only 20 pages on linear physics, doesn't seem much. I don't want to write the next Box2D, I just want a solid foundation. It has a trigonometry reference, that's a plus. Would you generally say it's useful for 2D games? Do you have a more basic math book accompanying that one?

#4996191 Only white textures on a Windows system with an Intel graphics card - How to...

Posted by on 01 November 2012 - 08:21 AM


I'm really stumped with an issue here: I'm working on a 2D game that uses SDL and OpenGL. But for some reason, all textures are white on one particular laptop, under Windows. It works fine under Linux on the very same laptop. It also works fine on another Windows system I have access to.

My only hunch is that it might have something to do with the graphics drivers. It's an older Dell laptop with a Intel 915GM/GMS graphics card, and the official drivers from the CD.

I have no idea how to debug this, what can I try?

#4994030 Game objects in a 2D game - sprites that contain sprites or sprites and scenes?

Posted by on 25 October 2012 - 10:13 PM

Is it otherwise impossible for Entities to contain other Entities? It's not uncommon to want a parent-child relationship between entities in a game. Say, there's a knife on the ground, and your character goes and picks it up. You could just "attach" the knife to the character, if you had that capability.

Hm. I guess it does make sense. That means the major problem is really that my widgets want to handle input themselves. But that's solvable if widgets are derived from entities.

Both solutions are reasonable, but if you're starting out by saying that Widgets are fundamentally different than Entities--by putting them in separate trees--then you can't expect to handle them as if they are the same. You could maintain your WidgetSpace separately from your Scene. In WidgetSpace things are oriented and positioned with normalized coordinates relative to the screen, in the Scene things are positioned in absolute coordinates relative to the world. WidgetSpace can forward input for Widgets to handle on their own, while Scenes can handle input for Entities.

Maybe it really does make sense if I don't try to force my UI into the same object hierarchy. I've discovered a new open source code base for inspiration: Battle for Wesnoth. Like my game, they have a lot of UI. And they have that distinction.

Anyway, I'm only working on the UI for now, being the first thing we want to get right. I'll worry about entities when I actually need them, until then it's widgets. But I feel I have a couple of options available now, thank you.

#4993679 Game objects in a 2D game - sprites that contain sprites or sprites and scenes?

Posted by on 24 October 2012 - 10:51 PM

What is a Widget? What inextricable properties does Widget possess? If it's synonymous with Entity, like Sprite was, then the answer is probably "nothing." A Widget on its own carries no inherent properties. You're almost always going to end up having an invisible Widget, or a Widget that doesn't care about input, or that can't move, or has no position, or has a position in 2-space instead of 3-space, etc. etc. To me, this just says that trying to fit your game objects into a hierarchy is a bad idea, they're not concrete enough. That's why the component based approach has caught on so well, it fits the problem space much better than a more vanilla approach to OOP.

Widget is definitely a meaningless term in general. But in user interfaces, it universally means "UI element". So yes, there are things that are true for all widgets. That's probably why OO and UIs where invented together Posted Image Widget isn't only the base class for code reuse, but for polymorphism, and understanding.

With my lack of experience in game development, I cannot say if classical OO makes as much sense there. I've read a lot about component-based systems lately, so maybe not. But my main sources of inspiration (the Doom 3 engine and Frictional Games's HPL1Engine) seem to be wired that way. (Both admittedly a bit aged, but I'm struggling to find good open source game code bases, let alone recent ones.)

The component-based approach seems like a good idea, definitely more flexible. But I'm not sure if it's the right choice in my situation. I'm working on a small-ish 2D game with pretty simple gameplay, mostly myself. You're saying: "It’s not that an inheritance based entity system is inherently wrong per se, but in large systems it tends to become an impossible to manage web of sloppy code". I'm not working on a large system, I think it makes sense to keep things as simple as possible.

I've faced the same problem. What I did is model Button as an entity that contains Drawable, Inputtable, and Positionable.

Hm. I think it makes a lot of sense to think about my game objects in terms of components, even if I don't use a component-based system. In my case this would be:

  • Can be drawn
  • Can be updated
  • Can be drawn
  • Handles its own input
  • Can contain other widgets

Looking at this, it seems I cannot reasonably derive one from the other. A widget is not updated by the game loop, it handles input itself and invokes callbacks. And it contains other widgets, to which it forwards any relevant input. Entities on the other hand are regularly updated by the scene, which handles all user input and decides what should happen to the entities based on it.

Now how does that distinction fit in with scenes? Should scenes be able to handle both entities and widgets? Should I have a special kind of entity that acts as a container for a widget? I'm stumped.

#4993466 Game objects in a 2D game - sprites that contain sprites or sprites and scenes?

Posted by on 24 October 2012 - 10:08 AM

How i think you should do it unless you find a better solution:

So you're suggesting I have a couple of concrete UI elements like Button and Image that use sprites (or what I would call them in the future) by composition? The problem is that Image is a pretty basic thing, actually used by Button right now. I've got more complicated UI elements that include multiple buttons, images and labels.
Regarding the scene graph, I think my approach basically works like that already, so I guess that's good Posted Image

Sprite is sprite, it's singular. It also does not have means for collecting input--that's far beyond its purview. What you may want instead is some base-class GUIElement. This class could provide default implementations for listening to and forwarding input, as well as adding and removing children. The classes that you derive from GUIElement can hold as many sprites as is appropriate for whatever particular element they are representing.

But what _is_ a sprite then? A visual representation of an entity? A "drawable"? I have so far been using the term synonymous for "entity", actually.

You're right, I could just rename Sprite to Widget and my object hierarchy would suddenly make sense. In Qt for example, widgets can be nested. But I just thought it felt wrong to call it Widget, since I'm after all working on a game here... There is a lot of UI, but there's more, and I don't want the UI to dominate the terminology in my code base. When I add characters moving around, they would probably end up deriving from Widget...

Then again, I guess I don't need to have my individual entities handle input like widgets would, my past games usually had per-scene input handling. I think I'm mainly struggling with how I can have my UI (screens and widgets) fit into the same object system as my entities and scenes. My initial approach was to opt for less UI-typical code and use entities and scenes for the UI instead. But one thing that was particularly annoying was central input handling...

#4968793 What was the development toolchain for the Apple II/II+ like?

Posted by on 12 August 2012 - 12:55 PM

I'm wondering was game development was like in the late 70s and early 80s. One of the dominant systems back then were the Apple II and the Apple II+, so I'm specifically interested in that.

Can anybody tell me what languages, compilers, editors etc. were used back then?

Here are some specific questions:

- What languages were popular for game development? Based on my research so far, it looks like 6502 assembler was dominant, but there were different assembly languages, right? What about C, was it popular already? Any games written in BASIC?

- What compilers were available/common for the popular languages?

- How was code written/read? It looks like BASIC code was just written from the shell, adding instructions by prefixing them with numbers and LOADing, SAVEing and RUNning the programs. Was there no visual editor? Did you really have to use LIST n-m to look at your code? How about assembler/C code?

- How was input/graphics/sound handled? Were there any abstraction layers and APIs or did you have to talk directly to the hardware?

I'm also interested in anything else that was noticably different from now back then. Like how were images/sound stored?