Olof Hedman

For all 3d graphics, the "camera" is just a useful abstraction for how to construct the view and projection transform matrix.

 

If it "moves" or not, is up to you as a programmer to decide, depending on how you want to look at it.

 

It's equally valid to see it as the camera moves around, as it is to see it as the world is rotated and moved around the camera.

The math will be the same.

 

I'd recommend you chose whatever you feel is intuitive, that usually results in better structured code.

 

A very common way is to construct the view matrix from an eye-position, a lookat-point, and an up-vector.

The "camera" would just be these values stored somewhere (maybe in a class called Camera)

 

Here is the code for gluLookAt, which implement this: http://www.opengl.org/wiki/GluLookAt_code

Maybe not a glaring mistake, but it can be a good habit to have in mind:

 

If you re-order the if-cases, you will optimize away two compares and jumps in the common case. that is, test for index >= 2 first.

 

(I'd use the if over switch in this case, just to have control over this)

With Xcode 3 (version 4 is sadly mostly single-window), I can have 2 or more full-height (50 lines) windows of code visible at once, even on my 15" notebook display.

 

Have you tried View->Hide Toolbar and View->Hide Tabbar in Xcode 4?

Then maybe "Use separate window" on double click navigation in general preferences to emulate the XCode 3 windowing behaviour.

 

For any platform, I usually chose the environment that is provided by the developer of the platform if available.

That usually coincides with having the best tools

 

So that would be VS for windows, and XCode for OSX

Even if you don't actually use UML later, or choose to just use a small subset of it for personal use to sketch your class dependencies (as I've found most people do), it is definitely something worth knowing about, and yes, it will probably help you visualize (and communicate) the concepts of OOP better. (both on paper and in your mind)

Makes me remember my best friend in highschool.

I don't think I ever say him use a variable name with more then 4 characters. mostly 3.

 

I guess it looked good together with the embedded asm he was writing.

 

He also didn't like to use circuit boards when building his electronics, because they were a waste of time and space.

Instead he build his circuits with all air-connections, in 3D... (yes, they did work, perfectly)

 

He's now pretty far into his academic career

The option to use LGPL is probably there mostly for political reasons.

 

Some people have a strong preference for anything GPL. 

You're using the Random class wrong. You should create an instance once, at startup, with a seed, and then continously call next on that instance, instead of creating a new one for each call.

 

You are not supposed to change the seed each call, and the coordinates you send in will just mess up the sequence for the random number generator, and make it produce less wellbehaved random result.

 

Using it properly should speed it up a lot

 

If you want reproducable result, you just need to save one seed for each level

You are converting 3x3 blocks to 1x1.

In src you step over every third line:

 

s = &src[iSrcPitch * r*3];

 

so you have to limit the number of times you do that to 1/3 of the lines in src.

 

same thing inside each line.

 

s[0] reads a pixel on the current line, s[width] on the next, and s[width*2] on the next after that.

Its gameplay mechanisms are pure 2D, though. Simcity 2000 and up are regarded 2.5D by some. Sure, a change in terrain height can mean higher land values, but you could emulate that in 2D as well.

 

I hold to my definition that if the 3rd dimension affects gameplay, it is counted as half a dimension if the rendering technique used is not full polygonal 3D.

Though it definitely is connected to the visualisation you choose to use.

 

Sim City 2k graphics is 2D, and the "emulation" of depth is achieved by isometric techniques.

 

If you would add terrain height change to any 2D game, you would need some way to show that the terrain height change had happened.

 

If you do this with some graphical effect, like some shading, a scaling, fog, etc, that give some illusion of depth, the game would then become a 2.5D game.

If you just have a number "5m above ocean" on every tile, then it remains a 2D game.

 

 

 

I must say though, that I'm a bit confused about the "3D games with 2D gameplay" though, that is, full polygonal 3D, but gameplay limited to 2D as the OP describes.

I'm not sure I would like to call that 2.5D, but I'm also not sure what I would want to call it  probably something contrived like "2D game with 3D graphics"...

You can't find the handedness by just looking at the coordinates.

 

Handedness only comes into play when you want to interpret those coordinates, and show it to a human.

 

If the 3d modeller worked in a LHS and you try to display it in a RHS it will look inverted from how the modeller intended, but there is no way to know what he intended without asking him. (That is, have a separate encoding in the file that says "this is modelled in LHS")

Modified code: http://pastebin.com/mvPR2snF
(Note: some changes are purely for preventing the optimizer from removing entire sections.)

 

I think you still have a number of issues in your code that skew the result.

One thing is that you do an float->int conversion for each int operation, this will likely slow down the int operations more then they should.

The other is that you use base 10 for the precision, you should use base 2, and then a lot of muls and divs will become shifts.

 

Fixed point is nice, and I find it pretty intuitive when you get the hang of it, have had to use it a lot on different ARM processors.

But you can write bad fixed point code too, probably easier then you write bad float code, and that can hurt performance.

 

Nice thing with ARM is that you can get shifts more or less for free, speeds up the fixed point code even more.

Also has a 32bit * 32bit -> 64 bit instruction so you can do muls without losing precision, very nice

Everything as a huge char array? Even if it 80MB?

 

A desktop PC has typically several GB of ram, 80MB is nothing

 

But if you need to conserve ram (maybe you use it for something else), it could be done in chunks too. 

Just read as much as your buffer is big, parse as far as you can, and repeat until end of file.

Cocoa and Cocoa Touch however are the same API with minor tweeks for touch.

 

A bit more then that, the whole ui and app framework is rewritten from scratch in cocoa touch, and even though there are a lot of similarities, they differ quite a bit.

There is this lib called chameleon that wraps the cocoa framework in something that looks like cocoa touch (for easy porting of iOS apps to OSX), but its not complete, and studying can give some insights in what differs.

 

But a lot of the classes, specially anything not directly ui-related, is (more or less) the same, so you are definitely helped by cocoa knowledge when starting with cocoa touch.

 

There is nothing that says you have to learn one before the other though.

Any further argument on this topic between you and me is futile, as we come out from different stances. Your goal seems to be shooting down people without the skills that you find necessary based on their one or two posts. My goal is to show them some ways how they could utilize the skills they posess to actually get a job in gamedev (it's completely another matter whether they will make any use of it or not).

Who knows, maybe your way is better. Happy hunting!

 

Or maybe my goal is discussing, while yours seems to be lecturing ;)

I've never shot down anyone for wanting to do anything, I just found a few points in your post I didn't agree with and told you why.

I'd say people in HR, Finance, Marketing, PR, IT and Legal have very limited influence on what game is made and how.
So that leaves the producer in the "other roles" that actually influence the what and how in any meaningful manner.

Sure, they are important in shaping the working environment etc, but those decisions isn't really that special just because the company happens to make games.

Sure, anyone in the house can use their people skill to influence somewhat, but that includes the janitor. Neither he nor the people from HR and finance etc will be invited to the meetings where stuff is discussed in depth and decided.

But I admit I used the janitor job for effect.
I also admit I havn't worked at a big game studio but I have worked at a medium sized (grew from 25 to 180 during my time) software/design studio in a creative field.

Maybe I have higher expectations on what it means to actually influence something though, since I've chosen to work at a small studio for exactly that reason, maximum influence on the what and how.

And I stand by what I wrote. On entry level, in AAA industry, you don't need to code or draw for the vast majority of positions, including those that aren't directly involved in development.

I don't argue that, but it's not really helpful to tell someone that say they want to make games that they could apply for a job at a HR department.

I can't code and I can't draw... ...yet I wanna be a game developer! This kinds of posts pop up on game development forums pretty frequently and a common reply to these is [...]

I read this as a hint towards the many threads where idea guys are shot down because they insist on being only idea guys and seem to refuse to even consider they might need to produce something tangible...