Don't use GLUT -- use the appropriate GL toolkit for your platform (GLX, wGL etc) and just don't create a windowed context.
We're offering banner ads on our site from just $5!
KatieMember Since 15 Jun 2006
Offline Last Active Dec 17 2014 02:20 PM
- Group Members
- Active Posts 848
- Profile Views 7,020
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Katie hasn't added any contacts yet.
Posted by Katie on 23 March 2013 - 03:05 AM
"This is another one reason as to why we don't see any AAA-titles on Java"
Minecraft is written in Java, Minecraft is not a "AAA" title. But I suspect that doesn't bother the now-multimillionaire author.
Java is plenty fast enough to write all sorts of games. Someone who's been playing with languages for a couple of months isn't writing a AAA title anyway. They're writing Tetris. And Java is a good choice to learn to write Tetris in.
I miss the days of Basic. When you could just turn the machine on and Basic was waiting for you. Didn't have all this crap about what languages and frameworks to use, everyone just used the Basic on their machine and moved onto using bits of machine-code when they were ready. And so people learned how to write game-loops and how to manage state and how to do collision detection and how to make a game actually fun without having a long debate on the internet about what tool to use because there was only one to hand.
Posted by Katie on 13 March 2013 - 03:00 AM
"If you want to code, code.
If you want to draw, draw."
And if you want to design games, design games.
Design board games. Write an RPG system and give it away. Design a CCG, print it out using a POD business-card printer. Playtest the things, am-publish them. Just get on with it. Bloody hell, this forum is constantly full of people whining that they don't have the resources to do games when the world is awash with print on demand houses and games components sellers. Design wargames -- that's how I got one of my games development gigs. I can code AND I understand how to simulate tank combat.
Games are games -- understanding what makes a game fun and how people interact with games and with each other while playing them is the experience you need. Want people to let you see what you can do with their $10M-a-month dev team? Might be worth demonstrating you can design a game with $50 of random components first. Because the guys who already ARE running those teams definitely can; Molyneux, to pick an example, apparently designed Populous as a boardgame to start with (using Lego for the modifiable landscape).
What better way to get hired than being able to send the company one of your games that you know is fun and letting them find out that you can make things people want to play. And if you can't do that, why would someone give you millions of dollars a month?
Seriously -- if you can't look a pile of parts and figure out how to make a game from it, you're not a game designer. Because games designers don't NEED a bunch of coders and artists to make something that entertains people. The medium is not the skill. And if you can't afford marble yet, sculpt in clay until you can.
Posted by Katie on 17 February 2013 - 01:13 PM
" actually wanting to do the job is worth far more than just the prospects of landing the job."
I don't know -- I've spent my professional life wanting to be a good software engineer. In general, that's only ever led to tears because although they always say they want good software engineers, almost all employers actually want;
- software engineers willing to do a bodge job in half the sensible time
- engineers willing to avoid the actual useful tools or the right way of doing things for what amount to religious reasons. (Eg; here's a copy of Excel. Please implement a database system in it... because we don't want to buy a database system because it'll be too complicated)
- engineers who are willing to put up with using substandard components "because they're already written" which is kind of like asking people to design aircraft around engines which are known not to work but have already been assembled or purchased...
- engineers who are willing to "program down" to the level of the least skilled person the company hypothesises they might hire.
- engineers who are willing to actually lie to clients about the safety, security or correctness of software
- Some or all of the above in combination.
It's dull constantly being asked to under-perform, especially when you're actually good. To be honest there are days (often many of them) when I wish I'd become a lawyer or an accountant. I'd never be brilliant at a career like that, but at least I'd only be as mediocre as people expected me to behave rather than constantly having to tone down something I enjoy being good at to a 4 or a 5 on the dial.
 You would be AMAZED at the kind of companies that do that.
Posted by Katie on 17 February 2013 - 01:01 PM
"Accelerated C++: Practical Programming by Example", Koenig.
Followed by other books from the same series when you need them.
Also, I particularly recommend "Beyond the C++ Standard Library: An Introduction to Boost" by Karlsson. It's a really good guide to the less hairy parts of Boost and how to practically apply them to improve your coding.
 Boost is a set of utility code, some of which has recently been rolled up into the language standard. They provide a lot of helper functions/classes.
Posted by Katie on 23 January 2013 - 04:28 PM
" Steel even contains Limestone, if I recall correctly."
Limestone is added to iron as it's smelted in order to combine with acidic impurities and make them solid; at which point they float to the surface and are either skimmed off before pouring or are just left behind if the iron is tapped from the bottom.
Posted by Katie on 20 January 2013 - 12:03 PM
"Should I put all vertex data to a single VBO?"
Whereever possible, yes. It means the whole vertex will be pulled into a cache at the same time. By having multiple VBOs, you're using multiple memory units which means multiple caches need to be loaded. Each will contain the vertex data for more vertices, but that's not necessarily useful; if you use the coords for a vertex, you'll use the normal data and probably quite soon, so the memory effort in loading it is useful.
If you have multiple memory units loading many verts into their cache, their effort may well be wasted -- touching vertex V implies nothing about when or even whether you will need the data for vertex V+1.
"If a group has, say 4000 polygons (which could happen for the player models), is it advisable to call glDrawElements once for the whole chunk, or should I cut it into pieces?"
Do the whole thing. Reason; let the driver do the optimisation work. It knows what shape the hardware is, and you don't. Don't try and second guess it unless you have a known crap driver you're trying to work round. Some drivers, for example, may take the min/max vert index and transform everything in that range and then bin the unused values. If you unchunk the data, they'll obviously waste more time on unused nodes. For the same sorts of reasons, try and make sure all the verts in a chunk are adjacent in your VBO.
You're also likely to transform verticies on the split boundaries more than once, whereas as one draw, they'll likely only be done once.
Posted by Katie on 20 January 2013 - 11:54 AM
High budget funding, but you don't know how to setup a company? You go to a company formation agent and buy one and rename it. 200 quid.
"They will be needed to sign an NDA but is there any other neccesary paperwork we should look at."
Um. Yeah. You're going to need an employment contract. And some HR policies. And you'll be wanting to get an employment lawyer to look at all this.
" I have consulted with some lawyers but most are not familiar with the technicalities of making game oriented companies along with game copyright and trademarks."
That's because you're thinking they're something special, but they're not. Just go find a proper business lawyer. Not a high street solicitor, an actual firm with a business group.
Are you really sure you're the right person to be handling this sort of thing? This is the noddy end of running a business and you're already resorting to asking internet forums. What's going to happen when you have to fire some of the staff and do it legally? Or work out what the implications are of ditching a publishing contract? Or the really complicated decisions like at what point in a dev cycle to start working on a second product...
Posted by Katie on 23 December 2012 - 03:48 AM
I did some work in this area; I don't think there would be major problems. The annoyance is that it's not just a single line of Java you need to write -- basically any event you actually want to use (screen touches, rotations, anything like that) requires a thunk to pass it into your NDK. On the plus side, once done, done.
You'll also need to think about whether you'll need to leave C++ and go back to Java to do things (to access other features on the phone). If you want to write something that uses screen taps and draws things, the work is pretty simple. If you want to start talking to servers, do GPS or use the camera or things like that then it gets complicated fast.
You can do this transition into C++ at any layer BTW -- you could do game logic in Java and the rendering in C++. It's just a call into a shared object -- a DLL.
Why did I do it? Simply because I'm more productive in C++ because I'm more familiar with it. If you're starting from scratch, you may be better off choosing the path of lesser resistance and working in Java.
Posted by Katie on 22 December 2012 - 12:47 PM
It's always easier to cheat. You're trying to solve slightly the wrong problem; You're trying to figure out how to run a system where you make random rain and then work out how to not have it enter the buildings.
It's much easier to do this in your level design. Make it "rain" in boxes. The raindrops start at the top and fall down (you can do this in the vertex shaders fairly easily). When they get to the bottom of the box they get recycled at the top.
You plonk these down in your level... at ground level in the streets, at roof level over the buildings. You should also then be able to cull them fast -- if the view is indoors, it can't see up anyway, so the overhead rainboxes are never rendered. (You can get away with the rain sequence repeating as well. You can also get away with using the same rain positions for all the boxes... add some distance fogging and no-one will ever spot the rain tiling :-)
Likewise your dust -- it lives in boxes. The player moves through the box, dust is generated, it drifts back down.. job done. The dust is never made where there isn't a box -- like inside.
The goal of games development is to make something that's real enough that if the player co-operates with suspension of disbelief looks right. It doesn't actually have to solve all the annoying things for real if you can cheat...
Posted by Katie on 06 December 2012 - 05:31 PM
You'll be back here asking how you have other characters carry things...
There are a couple of reasonable approaches. One is to have a true tree structure where objects can contain/consist or otherwise relate to other objects; rooms are objects which contain items and characters, characters can "hold" or "wear" objects, which in turn can contain other objects.
Lets you handle "examine gun in pocket of coat"
A simpler, but still useful mechanism, much used in games in the 8 and 16 bit eras is to give each object a "location" field which is an integer. If it's positive, the object is present in that numbered location. If it's negative, the object is being carried by character number abs(location). Location zero doesn't exist, so objects can be removed from the game world. Other location numbers can be "special" in various ways.
It then gets reasonably easy to implement "give" and "take" and then you can have puzzles where you need to stun the guard to take his sword (because when he's unconscious he doesn't attack you if you try to take objects off him) and use it to cut the rope...
Just give each item a map of properties, string->string. When a player runs "Examine X", you can check X to see if it has a "examine" property. Otherwise it's "nothing special".
You can then encode several other useful things. If the item has "get_message" you can't get the item, but the string is the message to print instead. If the item has a "text" property, then "Read X" works on it... and so on.
That's how you make the door -- it has a "get_message". Now that the door is an object, handling "Use key on door" is easy. It's a special case of "Use X on Y"...
Back in the 8/16bit days, you'd have a single routine for each verb. The routine would check the objects. So first off you check if the objects are "present" (held by the player or in the current location) and then you do; if ob1 = key and ob2 = door then unlock_door()
Unlock_door() would clear the "blocked" bit in that link and swap the "locked door" object for the "opened door" object. (by swapping their locations).
These days, if your language supports them, you may want a set of maps which map tuples of (verb_number, object) -> function and (verbnumber, obj, preposition, obj) -> function
Posted by Katie on 08 November 2012 - 11:24 AM
Posted by Katie on 03 November 2012 - 10:49 AM
"i want to program at the OS level in linux"
No you don't. Really, really, really, you don't. The only people who do this are people who are working on the OS. Everyone else uses the abstraction layers so they don't go insane and they do actually get some work done.
ncurses is good enough for people who implement shells, terminal media players, rogue-likes, interactive fiction games, tetris clones and a hundred others. It means their software runs reliably on thousands of configurations. It has had decades of development and debugging work by hundreds if not thousands of people.
Why would you give up all that? Because you imagine a performance gain? Painting a 1000 character display? Every screen refresh perhaps? On modern machines which are quite capable of repainting million-pixel displays at 50 or 60hz?
Why is this place so full of people who want to spend their time re-implementing these sorts of layers? Is it really just misguided masochism? Why do people want to faff about doing things like this instead of writing actual games?
Posted by Katie on 01 November 2012 - 04:33 AM