Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 15 Jun 2006
Offline Last Active Aug 22 2016 06:51 AM

#5307184 Preventing overengeneering

Posted by on 22 August 2016 - 06:54 AM

"When in doubt, use brute force" (Ken Thompson)


It's what powered the development of UNIX. It's why it's a) full of singly-linked lists and fixed-size arrays and b) was written in a few months by a couple of people.


They always presumed that at some point their known-naive algorithms of searching linked lists iteratively would need replacing, and they did -- but it took decades for some of those uses to need that performance. And by the time that came around, they had a lot more people working on it....

#5303080 Mmorpg Idea.

Posted by on 29 July 2016 - 07:26 AM

"I was thinking to write GamePlay and how will in game systems work."


Jolly good. You'll just need to get several tens of millions of dollars to pay your software developers with and you're ready to go.

#5295935 Pros/Cons of coding alternatives to std::algorithm?

Posted by on 10 June 2016 - 03:53 AM

"I always felt like it's probably a bad practice to do so."


It's not if it does the job. I get to say it again; You don't need code to run as fast as possible -- you only need fast enough


Build it using the BIGGEST tools you can find -- the less work you have to do the sooner you can get a project done, profile it, then replace only the sections that mean you're not hitting your target.


Your goal is a completed project, not a tiny section of very-very-very-very spiffy code.

#5285785 Should getters and setters be avoided?

Posted by on 08 April 2016 - 06:59 AM

Methods on objects should be verbs or questions.


Sometimes it's appropriate that the verb is to set some state.


But generally no, the state of the object should not be visible or changeable from outside the object. So you don't need getters and setters.


If you find yourself with a "bag of values" object, just make it a verbless bag of objects. And make all the members public and save a bunch of typing.


One of the common flaws of developers is that given a setter interface, they try and drive the objects through it, leading to pages of boring settering code instead of a single verb operation to abstract that away -- and which, appropriately named, tells you what it does.

#5278439 "check before flight" list - for OpenGL

Posted by on 27 February 2016 - 08:20 AM

  • Did you clear the depth buffer before trying to using it.

#5277849 Manufacturing chain for paper

Posted by on 24 February 2016 - 03:21 AM

Paper/card is also used as packaging in a lot of industries. Think about how much cardboard/paper Amazon gets through.


When I moved house a decade ago, I ordered a bunch of 84 litre packing plastic packing boxes from a company in the UK which makes them[1]. Each of them arrived in a cardboard box, which we reused for packing light stuff in...




[1] They have locking seal lids which meant my Lego collection could be moved at minimal risk.

#5277848 Black screen when trying to implement ibo

Posted by on 24 February 2016 - 03:17 AM

"uint16_t is the same size as short?"


Usually, yes.


" Also I still don't understand why can't the indexBufferData work with GLfloat? I don't exactly understand what is the problem."


The index buffer is a set of array indices to use. Passing "7,47,998" means "draw vertexdata[7], vertexdata[47], vertexdata[998]". So floats don't make any sense. In C++ (and most other languages) you can use floats as array indexes, but that's only because they're being silently converted to integers while you're not looking... OpenGL is just being stricter about what types it'll accept. This is largely to simplify the work of the driver and the hardware by making you get things right to start with -- for example mobile phone OpenGL only takes short ints as indexes. Anything else is an error -- this makes the code inside the OpenGL driver simpler (and hence faster). The philosophy is that it's not OpenGL's job to sort your types out for you and most game developers would complain if it spent time doing that work when they just want triangles drawn as absolutely fast as possible.

#5257704 MySQL applications for a game

Posted by on 17 October 2015 - 01:28 PM

Or just a shopping list application. Multiple users, multiple lists, multiple things in a list. Login system, shopping list display, checking things off it. 


Which is rather quicker than an entire MMO.... and something you can just hand the entire source code of to someone. AngularJS as a frontend would be a big win, but regular boring HTML would suffice, something like Python running a resty API somewhere and a MySQL in the backend for the storage.


If you turned up having done something like that, we'd definitely consider that sufficient MySQL to get you into the interview. (We're not finance but we hire database-manipulating type people).

#5257471 Advice for start-up

Posted by on 16 October 2015 - 06:03 AM



What are you bringing to the table? You'll need one or more of;

  • Experience in the business side of gaming -- contacts with publishers and so on, with involvement in a couple of titles.
  • Experience as lead developer on a games project.
  • Several million dollars.

#5257453 Game of life on GPU question...

Posted by on 16 October 2015 - 02:59 AM

"I need a way to detect this."


Welcome to the "halting problem". (Life patterns are general computers and hence determining their termination falls under the halting problem).


There's no general way to detect these loops -- While two-stage cycles are quite common, you can get three stage... and four stage...


In fact you get N length cycles with a probability of something around 1/N. 


There are also sequences which don't repeat exactly, but also don't produce new information -- the famous "r-pentomino" settles down into a sea of static objects, blinkers and a couple of gliders. The blinkers/statics form a simple loop of 2, but the gliders are more problematic -- while they repeat their internal pattern, they move across the plane so the generations aren't identical.


The good news is that because life is forwardly deterministic, if you see ANY generation you've ever seen before, you know you've entered a loop.


So one simple approach might be to hash your array and keep the hashes. If you see one again, it's a loop.


It won't help you with the gliders... you'll have to get MUCH more creative with them. Note that there is an arbitrarily large set of moving-but-effectively-unchanged objects. Collectively they're call "spaceships" and there's a couple of dozen of them. (There's a catalogue at http://www.conwaylife.com/wiki/Spaceship)


You could measure the expansion of your life frontier (the boundary of live cells) and the count of total live cells. If it steadily increases at a linear rate for more than a certain amount of time, you could conclude that you have a looping system along with a cloud of spaceships moving away from the objects. Spaceships move at known fractions of c -- a glider is c/4 and after 4 cycles it returns to the same number of cells... The problem is that if you have (say) a 5-blinker in your static objects, your loop is now 20 generations, so what you're looking for in that system is a long-term linear trend in the boundary growing at some fraction strictly less than c while the number of cells oscillates through a set of counts (which annoyingly can also be arbitrarily long...)


To emphasise there is NO general purpose solution -- it's demonstrable mathematically for this class of systems that you cannot produce one and trying to will consume periods of time bounded only by your lifespan.


You can get a "good enough for me" solution so aim for that.

#5256332 Tell me the 10? ways to API wisdom

Posted by on 09 October 2015 - 03:29 AM

It's all done with buffers these days. You allocate some blocks of memory and stuff data into them and then point your operation at the buffers and say "GO!".


If you've used 1.2, it's like using the array systems, only you don't allocate the arrays in your program's memory anymore, you just get the API to give you a pointer to the memory.


The other thing is there's no standard pipeline. So you HAVE to use shaders. And that means you have to do the matrix work to produce perspective projections, camera matrices and so on. The disadvantage with this is you have to get everything working at once before you can see any results. TBH, it's easier to go pinch some known working code and go from there because there's a lot of moving parts to all get running.

#5255960 how to follow up on copyrights/patents

Posted by on 07 October 2015 - 01:43 AM

" I could go download a patented font, upload it to dafont.com, and ask $10 dollars for it. "


Well yes, that's one of the problems. People spend ages chasing down infringers like that. And yes, you could theoretically download a font in which someone else has an interest. And yes, they could well wander up to you in a couple of years time and ask for a share of your profits after demonstrating that they're the true owner of the font and hence you used it without a licence...


This is an important lesson -- don't use sites like that. Use sources you can TRUST.

#5255958 how to follow up on copyrights/patents

Posted by on 07 October 2015 - 01:36 AM

My understanding of fonts is the same as Tom's -- using the font is covered in whatever you paid (or agreed to) in order to get hold of it in a form where you could use it to start with. The licence covers the file you load into your editor, not the image of the letters in a given size/colour.


It's the only way it could work really -- after all the original use of fonts is to make a document you print out and give to someone else...

#5255957 Drawing graphics in C++ w/out APIs?

Posted by on 07 October 2015 - 01:31 AM

Your opengl implementation will probably be written in C. It'll communicate with the GL hardware by loading blocks of instructions and data into shared memory. Exactly how to achieve this is often commercially sensitive information -- the various device manufacturers are in competition with each other for speed... and consider the actual hardware APIs to be part of what constitutes their commercial advantage. This is why even the Linux drivers are often opaque code blobs (upsetting purists) instead of readable source.


Why do you want to do this?

Quite apart from anything, getting it working on one card with one kind of GPU won't give you much portability...

#5255617 Is Python good for 2d - 3d games?

Posted by on 05 October 2015 - 02:37 AM

Python isn't the fastest language around so speed-reliant code is difficult to write.


On the other hand, it's certainly fast enough to do the sums involved in moving a few hundred sprite objects around the screen -- one lets the rendering system do all the looping work.


The advantage, from a learning point of view, is that much of the boring fiddly work of who owns which bits of memory is done for you so you can focus on the more interesting parts.


Many of us grew up writing games in a mix of BASIC and assembly language on 8-bit micros, and the kinds of games which worked well there can be written these days in Python much more easily. M&B is, as Sean says, a bit out of reach, but rogue-likes, 2D puzzlers and platformers, shoot-em-ups and so on are within reach (only with better graphics than the 8-bits!). I wouldn't be surprised to find that with a little extra work, things like Starglider could be done in Python these days.


The trick is to design a game that doesn't involve large amounts of data.


Large, of course, means something slightly different these days. A z80 instruction to block copy memory[1] costs 21 cycles per byte copied. You only get 50-100 thousand cycles per 50th second TV field on most 8-bit micros. So you can realistically only copy a few kilobytes of memory per frame..  I had a quick naive play with some code and python on its own is capable of copying 400k per frame. So even in plain old python you've got 100 times as much processing power as we had back in the early 80s...




[1] LDIR, for reference.