Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MaximumZero]

I'll be taking C++2, Java and Visual Basic next fall, so hopefully I'll be able to broaden my horizons a bit.

Anyway, I'm not too keen on becoming an analyst anyway. I'm already pushing 30.

[qwertyuiopas]

Just about anything to do with graphics is going to use OpenGL, DirectX, or a library built on either of the first two. If you look hard enough, you are almost guarenteed to find that somebody already wrote a nice graphics framework that does all of the tricky drawing for you, leaving only a simplified interface that does just about anything you want it to, with half the hassle of doing it yourself.

[MaximumZero]

Oooh, shiny. I'll have to keep that in mind.

[devek]

So, it's n00b question time! What skill/language will I need to make stuff, actual stuff appear on screen? I'm sick of seeing the DOS window.

That requires a complicated answer. No language itself can talk to the screen, they rely on APIs to do their bidding. The api itself has nothing to do with the language, even though some apis are built for certain language.

Direct access to video is done by openGL. It isn't just for 3d applications, applications like Firefox use it, and api's like Java's SWING use it. openGL is supported on everything, you can use it on iphones, pcs, macs, linux, the ps3, and just about anything that has graphics. openGL may be a little complicated for writing a simple application though, so you may want to look for an api that is built for what you are trying to do.

SDL is popular for 2d games, it uses openGL to draw to the screen but it also provides many useful features for game design such as sound and keyboard input. Stonesense uses it and rightfully so.

For desktop application you need a widget library. Some are platform specific like win32, windows forms, or MFC. They are a bad idea to use because you're really limiting yourself by them, you should instead of cross platform widgets like QT, GTK, or wxWidgets. On windows they will use win32/opengl to do its bidding, or xlib/opengl on linux and it won't matter to you. QT is used by all the major DF utilities like Therapist and Runesmith.

I'll be taking C++2, Java and Visual Basic next fall, so hopefully I'll be able to broaden my horizons a bit.

Anyway, I'm not too keen on becoming an analyst anyway. I'm already pushing 30.

Java is useful, especially in business and server applications. You never know what type of machine your code will be deployed on, the confidence that it will "just work" no matter what the pointy hair boss decides to do will save metric buttloads of time hehe.

Visual Basic isn't something you will need if you know how to program. If someone doesn't know much about programming and wants to write a simple application, Visual Basic is great for that. Look at the Lazy Newb Pack for example. I'm not insulting the authors, they shouldn't have to spend years of their life learning programming just to write that and I think they would agree

[Gantolandon]

Were it not for the fact that I want objects larger then a single node, that will have to do checks on many nodes at ones, so a large grid made of links will make this very hard to do. I would prefer to do this all with an array of atoms, but then checking turns into a bitch. I could, of course, give the atoms bidirectional navigability to see the array, or at least what ever is holding the array, and tell it when they are doing something, but then again it was most likely telling them they were doing something, and the system doesn't seem very object oriented at all.

It becomes much, much easier with a two-dimensional array storing your nodes. This way you can just get the terrain you need to destroy with several simple calculations - you just need to know which ones are inside the circle (with the starting node as its center).

You probably don't even need a graph of nodes (seriously, are you going to pathfind through them?). What you need to know is their position - which you probably store somewhere anyway - not neighbors.

[Max White]

While an array for their position is ideal for collision detection between the nodes that naturally appear and a character laid over the top, it makes life hard when trying to figure out the reactions between nodes. For every water part, I would need to do a check for everything I want to react with water, such as magma. This is when linked nodes is ideal.

As such, I am forced to choose the lesser of two evils, and as Virex said, the quad tree, for best compression and low CPU use, fits more naturally into linked nodes.

So yes, as it stands, I am seriously going to have to path find through them.


EDIT: So currently watching a lp of terraria, and it dawns on me that they have something similar to what I want, but with larger blocks. Although they have a great lighting mechanic, it isn't something I see as being useful to this game, so they might free up some usage. But the lighting does seem to make it blatantly clear that each block is a single unit, rather then larger blocks that can be split down, and they have a huge world to do handling of, including some sexy water physics. If you had to guess, how would they have achieved that game?

[MaximumZero]

Okay, so back to the n00bz stuff. I always stick with cin and cout, but I know, know, that my prof is going to spring a printf and scanf section on us in the final. Long story short, I suck with them, athey're not in my textbook anywhere, and my Google-fu is weak atm. Anyone know of a halfway decent tutorial?

[devek]

For libc functions, check the man page

http://www.freebsd.org/cgi/man.cgi?query=printf&sektion=3

[MaximumZero]

Thank you muchly, ser. That'll come in handy.

[olemars]

If it's any comfort, that final should be the only time you'll ever need to use printf and scanf. Wait, I guess that's actually kind of depresssing since you'll have to study up on something useless. We consider it a bug if we find a printf in our code.

I guess it's ok to know how the old C IO functions work in case you encounter them at work later, so you can rewrite that bit into something less retro.

[MaximumZero]

Final ovah! I did okay, I think. We'll see.

[devek]

99% of programmers are dumb as rocks, you'll do fine

[Nadaka]

I am uncertain if it has changed much, but in 2001, an associates degree in CS was worthless. I strongly suggest that you make sure that you get real world practical experience. Preferably paid, but work on a moderately successful independent project would work as well.

[Max White]

99% of programmers are dumb as rocks, you'll do fine

It helps to stop them from trying to do anything smart that will cut through the business rules like a chainsaw through hot butter. A smart programmer makes deadlines faster, but then everybody who has to work on the system after him spends half their time correcting he's awesome magic quick fixes.

[Starver]

It helps to stop them from trying to do anything smart that will cut through the business rules like a chainsaw through hot butter. A smart programmer makes deadlines faster, but then everybody who has to work on the system after him spends half their time correcting he's awesome magic quick fixes.

Reminds me of one of those "legendary programmer" stories that I was once told.  The kind of person who manually optimised the disk access (on an old drum-drive) so that when certain data was needed, it was to be found on the bit of the drum that the head was about to pass over.  When a system delay was needed, he'd change it so the various bits of data were slightly before that point so that there'd be a natural system delay while a nearly full spin of the drum occurred and the seek-time occurred did the job of providing the necessary delay without any otherwise useless loops.

Called upon to make a player-vs-computer strategy game of some kind, naturally he made it a practically unbeatable player.  Demonstrators at trade stands got Management to force him, against his will, to change it so that a hidden override button would make it play worse for their more valued potential-clients to make them win and feel happier and more likely to buy.  But, for some reason (very possibly not unrelated to his effrontery at being asked to mutilate his code in such a way), the button now apparently made it even more aggressively unbeatable.  And, the strange thing was, when other coders were asked to look into the code and 'correct' it, not only could they not work out why a lot of the code was written like it was and how to make it play the game 'worse', despite there obviously being an effect, they could not find anything at all in the code that even registered the fact that the override button was being pressed in the first place!


(I'm sure that some long-term geeks, who have not been dipping sometimes in and mostly out of the sub-culture as much as I, know of a good link to a better version of this tale, but the above will have to do for now...)