Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 26 Feb 2007
Offline Last Active Yesterday, 01:53 PM

#5157891 Metal API .... whait what

Posted by Ravyne on 03 June 2014 - 12:00 PM

I would hope that this might finally convince Khronos of the need for a more drastic re-imagining of OpenGL. Hell, Introduce a new open, low-level, cross-platform 3D API if they have to, but they need away to break away from the legacy and move in a different direction than what they are now. Their latest proposed enhancements gain performance but lock you into certain patterns that you or your program might not favor, and still places a lot of burden on drivers.


Everyone else is ready to move to the automobile, and meanwhile Khronos intends to build a better horse.


Equally interesting is what this might mean for Android -- GLes (or Unity) has been the traditional cross-platform layer between iOS and Android Graphics. Android mostly lacks the high-end mobile gaming market already, but when Metal becomes the API of choice for AAA-style mobile games, and it looks to be a stone's throw from D3D12, it might boil down to iOS and Windows Phone serving up high-end mobile games. 

#5157619 Is working in terminal/console really a waste of time?

Posted by Ravyne on 02 June 2014 - 01:51 PM

Some amount of context is necessary -- For a complete beginner, working at the console is one of the most frictionless environments for getting output from your program -- its that quality of little or no friction that's really what we're after. Many other simplified APIs, even graphical ones, approach that level of ease-of-use, but none really match it. SDL is a good example of that, but even still there are several speedbumps that I would not expect a beginner to know how to overcome -- First they need to know that SDL exists, where to find it, where to put it after they've downloaded it, how to configure their build settings to find it, and at least enough code already to make it do something. If they get those last bits wrong, they'll get a cryptic error message most times that experienced programmers recognize for what they are, but which are opaque to a newbie. Even if they have experience in another language like C# or javascript, C++'s linkage model is different enough to be troublesome.


But console programs "just work" in basically any language and environment unless the installation is truly borked.


You can do a lot from the console -- Its still my go-to when prototyping non-graphical components, and for tools. Whether in C++ or C#.


I would encourage people who are interested in games to move onto a simple graphical API like SDL when they are comfortable and as soon as the need for more than the console can provide arises. You can do things like animation in the console, but you start having to build infrastructure that's distracting from the principles you really want to learn. When the scales tip towards a graphical API you shouldn't be afraid to move over, but neither should you feel like you're obsolete when the scales tip back the other way. Choose what enables you to learn most effectively and efficiently, rather than being fashionable.

#5156809 Next step, making a company?

Posted by Ravyne on 29 May 2014 - 02:19 PM

You probably want to speak to a business lawyer and possibly a financial adviser -- they will tell you what structures are best for protecting you, personally, from any failings your business might experience, the pros and cons of various structures, and how best you can compensate yourself from your company's earnings.


Laws are probably very different where you are, but for example an LLC here in the US protects your personal wealth from claims against the company. Here, you need to have a corporation to offer stock (IIRC, I may be wrong) even to employees or yourself. I know of some people who form corporations so that they can pay themselves a modest, regular salary (if they can afford it), but they effectively pay themselves a bonus by issuing themselves a dividend on their stock -- this is done because it offers the greatest tax advantage for themselves and their business.

#5156568 What are constant references used for?

Posted by Ravyne on 28 May 2014 - 04:23 PM

A const reference is exactly what it says it is: the reference itself is always const and must be initialized to refer to a valid object, const means that the object can't be modified through the reference.


This is why its advisable to take parameters passing large objects that you don't intend to modify as a const reference -- even if the object itself is not const, passing by const reference ensures that the function can't modify the object. It helps enforce and documents the intended contract of the function. This principle need not be used in conjunction with function parameters though -- a const reference is useful any time you want to enforce immutability of a (potentially) mutable object, it just does so with a different name -- that of the reference.


A const reference can reference both const and non-const objects, but you can't take a non-const reference to a const object, so there's no backdoor to modifying a const object. At least not without further subversion of the type system.

#5155261 5,000+ art assets licensed CC Zero

Posted by Ravyne on 22 May 2014 - 01:27 PM

Really great and kind of you to make these available so freely. I'll definitely be downloading when I get home and making a donation greater than the minimum. I'd encourage everyone to do the same, whatever they can afford. Even if you only ever used these assets as placeholders, your personal time-savings will be well worthwhile. Plus, having clean placeholders can give your early project an edge with would-be-fans, or in attracting would-be-contributors (even artists!) to your project.

#5155255 Creating a Console from Scratch

Posted by Ravyne on 22 May 2014 - 01:11 PM

Start learning VHDL and be ready to think in ways that neither C nor Assembly have taught you. Be prepared to to diagnose and fix bugs that have to do with signal propagation latency. Be prepared to design a CPU, GPU, and to generate a proper video signal.


After that you get to program it in not assembly, but machine-code -- or you get to write an assembler. When there's a bug in your application, it might not actually be in your application code, it might be a flaw in the code that defines the system. And you won't have a debugger for any of this, so get really used to debugging from memory-dumps.


Its certainly doable -- people have done it. But to say you and your friends have "some C and assembly experience" is basically equivalent to saying you and your friends have a dream and some gumption. Realize that you've got a long, long road ahead of you. This project is on the scale of a thesis project for an Electrical Engineering degree, except without the benefit of 3+ years of said degree program to get you running.

#5154132 How much to pay artists?

Posted by Ravyne on 16 May 2014 - 04:17 PM

You're not going to find a rule of thumb. Its going to depend on the level of quality you are willing to accept, the number, size, and detail of the pieces, and schedule you need things to happen on. Costs are generally commensurate to your expectations, bounded at the top by what you can afford to pay, and bounded at the bottom by what any capable artist is willing to accept.


In general, its probably true that very experienced artists more than offset their additional costs by being able to produce high-quality work efficiently. You might be priced out of retaining artists of a certain skill level, but I would caution you against any thought that an artist charging less per time unit or work revision will save you money over one who charges more. With less experienced artists especially it is nearly impossible to vet how much value per dollar they will produce. I once tried out a novice artist, offering $15/hr for a trial period of 10 hours (with the stipulation that the resulting art had to be of usable quality). Two weeks later, a week late, this artist delivered 22 static, 32x32 tiles that were flat, boring, and generic, claiming to have burned 8 hours of their budget. In the meanwhile I really needed art to work with so I took 4 hours one afternoon to knock up some tiles. Being a somewhat competent tile-artist who would simply rather have liked to concentrate on the code, my tiles looked better none-the-less. Do your diligence before committing significant resources to any artist, but especially a novice one.

#5154099 2D rasterizer resources and book

Posted by Ravyne on 16 May 2014 - 01:46 PM

Rasterizing is always 2D -- Software Rendering books will talk about the 3D pipeline a lot, but the whole point of the 3D pipeline is to transform 3D things into 2D things so that you can rasterize them.


Computer Graphics: Principles and Practice is the classic textbook. For your purposes, you probably want the Second Edition in C. The original Second Edition had code samples in Pascal, and the newer Third Edition focuses on modern rendering hardware. IIRC, it spends a good amount of time talking about glyph rendering (text and symbols using vector descriptions), shapes, and bitmaps. It also goes on to discuss 3D matters like transformations and lighting.

#5153632 Less Constricting 3D Engine with "Low Level" Code Access

Posted by Ravyne on 14 May 2014 - 01:13 PM

Something like SDL 2.0 or DirectX Tool Kit (DXTK) might be close to what you're looking for. They help take care of the inane details of dealing with the platform, give you some nice APIs for doing common things, and integrating other higher-level functionality (like say, Bullet physics library) is fairly well documented by the community, but other than that you can have a straight-up 3D API interface with little or no interjection. But, teh downside for you might be that these things are not engines as you know them -- You'll probably have to roll a fair bit of your own tech (or integrate third-party solutions) for things like materials, models, etc.


That said, many people seem to find things like Unity adequate, and when I come to a point of feeling like an engine or library is stupid, myself, I've learned over time to take a step back and ask myself whether it really is, or if I've just not taken the time to learn it right. Your reaction might be something of a symptom of NIH syndrome, make sure its not because its going to take a lot of time and effort to re-implement the things Unity will give you (not to mention that Unity is debugged and battle-tested).

#5153390 The acceptance of gold loot in RPGs

Posted by Ravyne on 13 May 2014 - 02:09 PM

Unless it contributes to the gameplay, I say give me one currency. I'm here to play a game, not do mental arithmetic or collect a virtual change-jar full of fake copper coins. On the other hand, if there were a sort of 'elite' currency that was the only way to acquire certain high-end goods (perhaps, simply as a practical matter of costs, and no one wanting to take two room fulls of copper as payment for a ship) that would be good. Or perhaps if opposing kingdoms had their own currency and didn't accept the other, or accepted it at a reduced exchange -- that might support some interesting gameplay choices.

#5151743 Splitting an image into tiles

Posted by Ravyne on 05 May 2014 - 06:40 PM

So, first of all, fix your loops -- having y inside x is terrible for your cache performance.


The general answer to tiling the image is to wrap your y-x pixel loop in another y-x tile loop. Divide the height and width of the whole image by the height and width of your tiles, respectively, to get the number of iterations in your y-x tile loops. You'll need to take special care of images that don't divide evenly into perfect tiles.

#5150996 RefCount and Manager

Posted by Ravyne on 02 May 2014 - 03:44 PM

All modern c++ environments have it, its even been in Visual Studio since, IIRC, VS2010 through the tr1 namespace. Otherwise, Boost (which the the standard smart pointers are based on) has you covered with support stretching back even further.


Ref counting is usually a consequence of such managers, but whether the manager itself actually holds an interest in the managed object is up to you. If your philosophy is that the manager always holds an interest in the object, then it should hold a shared_ptr itself, and hand out shared_ptrs to clients, this is arguably the most straight-forward system but you have to periodically sweep teh manager for resources that only it owns when you want to eject them; if your philosophy is that the manager exists *only* to give out handles to resources it loads (without redundantly loading resources)--and if you are happy with releasing resources aggressively-- then it should hold a weak_ptr itself and hand out shared_ptrs to clients. This effectively ejects a resource as soon as it goes unused, but you still need to sweep the manger occasionally for weak_ptrs that don't reference anything.


If you wanted resources to be released lazily (in other words, maybe you don't want to free the resource immediately because you want to do it at a convenient time, or you want to keep everything loaded in memory until memory becomes a problem) then you need to define what your garbage collection policy is, and some combination of smart pointers and sweeping will get you there. This is the most involved approach, and probably more than what most small project need.

#5150790 Can an employer legally own work that you create outside working hours?

Posted by Ravyne on 01 May 2014 - 01:23 PM

I tend to agree that its a moral violation for a company to claim work that is: done outside of working hours, done without company equipment or facilities, done without company code or technology otherwise inaccessible to the general public, and unrelated to the nature of your work for the company.


Legally, it depends on the employment agreement and your state. Some states say that, essentially, any salaried employee owes his work to his employer regardless of where the work was created, some states place strict limitations on what your employer can claim. Most fall somewhere in the middle. Regardless of state law, companies usually use the same employment contracts all over, with a simple provision that contract terms are void where they are prohibited by state law -- honestly, I think this itself is fairly scummy, as this often obscures the rights that an employee has from said employee, who are left to think certain clauses apply even when they may not. The supposed benefit of these rules is that it prevents an employee from claiming to have had that "Eureka!" moment outside of working hours, and then holding it ransom to his employer or spinning off his own company or IP venture.


The rule of law is fairly clear from state to state, but enforcement is another matter. You don't hear about such things often, so it stands to reason that employers go after employees for outside, unrelated work, only rarely. I think in practice, the bad juju of going after an employee's work that is clearly outside the scope of his duties at work aren't worth a simple cash grab. To be known as a company that would do such a thing makes it even more difficult to attract or retain top talent. The risk of alienating the talent they need is probably seen as costing more than what a quick score would bring in.


Here at Microsoft we have a 'moonlighting policy' which is essentially a set of agreements we hold as employees, that if a brief review from the legal department finds that we have upheld those agreements, that we are protected from Microsoft ever making a subsequent claim.


Also, keep in mind that any employment contract is exactly that -- its alterable just like any other contract. Businesses will be extremely reticent to modify it, but in all likelihood if they've made you a job offer they are willing to make reasonable exemptions at your request if you are firm about it (however, they could decide to simply not employ you too). It can be as simple as striking out a clause or writing a new one in, and having all parties initial the change, or adding a rider.

#5150050 Applications vs. Webapps

Posted by Ravyne on 28 April 2014 - 01:14 AM

-Additional development complexity. More scaffolding, more libraries/frameworks, dependencies, tools, concurrency considerations, sessions, knowledge and so on are required...you probably know this, but I don't take this one lightly.  Complexity level vs. a Java thick client isn't even close, IMO.
-More complicated server side to deal with. Depending on environment complexity and factors like whether you have a pack of security goons nagging you, this can get bad.
-Harder (and often slower) to debug web-based stuff
-Net connection required, no "disconnected mode" (this may be a moot point with a reporting application if there's a remote database involved)
-Loss of easy access to useful local functionality such as the operating system clipboard, disk storage (without having to bother with cookies and such), screen captures, etc.
-DHTML still sucks. CSS & DOM are the 800lb gorillas in the room and they're still not pretty. The more browsers you're coding for, the worse it gets. But this may not matter in your environment if you're standardized to one browser.  Dev frameworks make this easier but they still need to be updated to keep up with the browser mess.
-Not sure what tools you have available, but relatively speaking, web dev front end tools generally aren't much fun to use - assuming your tech of choice even has one.


To be fair though, most of those that seem most hairy are not inherent problems in the platform, but a question of having people with the right know-how. From a business perspective, absolutely what resources and skills you have to carry out an implementation matters -- it probably matters more than just about any other factor -- but lets not be confused that they are insurmountable. I don't think you meant to imply as such, but what you said might read that way to someone less versed in these matters.


Also, if this is an app meant to run within an enterprise, then many of the real (but likewise not insurmountable) issues with browser-compatibility or feature-set melt away. Many people will decry web-apps as a total no-go due to the problems that arise from the variety of browsers you would have to support to deliver on the promise of "runs anywhere" -- To that I say, loudly, "So What?" -- Pick a browser, any browser, that supports the features you need and declare it as your supported browser. On a corporate network, the powers that be absolutely can make it so. Even in the Internet Frontier, 300 million people have a modern chrome browser installed, that's a pretty damn good install base by any measure.

#5150049 Applications vs. Webapps

Posted by Ravyne on 28 April 2014 - 01:02 AM

You have to consider the all the requirements --


If the program needs a connection to the network to do anything useful (e.g. it queries a database or reads/writes other network resources) then you need to have network connectivity one way or the other. On the other hand, if you can do useful stuff without a network connection, then a program that can be deployed on a workstation won't be brought down by a network outage.


How much processing power does the application need? Are you better off spreading that out among each user's workstations, or do you have a big enough on-premises server to handle the number of concurrent users you expect? All possible users? 3x that, if the company grows? Does the application scale up, or does it scale out?


What are the things you could do if the app lived on a server that would be difficult to do in an app? Collaboration? Continuous analytics? real-time analytics?


Modern web applications can be very, very robust and capable. Google has google docs, Microsoft has a very feature-rich IDE in beta. The web has come a long, long way since forms and post-backs. There's effectively nothing you can't do in a browser today, as long as you're happy playing in the sandbox that browsers give you.


The general benefits of running an app on a server are that you have control of the environment to a greater degree, and you don't have the (potential) headache of deploying and maintaining the app across a large number of workstations. This can have fringe benefits like being able to roll out new features and bug-fixes rapidly and incrementally (obviously, well-tested first), something that's too costly to consider when 10s or hundreds of workstations need to be kept in sync.


You may have to tow the party line, but it sounds as if your boss is very old-guard, and might be concerned that a changing world will leave him out of a job. He might not be up on the state of web development, or perhaps he is, but knows he doesn't have the expertise on staff to make the transition in a cost-effective way, or quickly enough to meet milestones. There are countless good or bad reasons to not do something, even if that something really is a great solution.