Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 26 Feb 2007
Offline Last Active Yesterday, 09:31 PM

#5212820 How do I know if I'm an intermediateprogramming level?

Posted by Ravyne on 24 February 2015 - 07:19 PM

Said most simply -- You're not 'intermediate' until you know exactly why you're not yet an expert.


Kidding aside, though, you're not an intermediate programmer in any language just by ticking things off a list. If there's any meaningful definition at all--and its very likely there is not--its probably something that requires both a working (but not expert) knowledge of all aspects of the language, and a body of experience using that knowledge to solve real, non-trivial problems in defensibly elegant ways.

#5212819 blast a solid black circle

Posted by Ravyne on 24 February 2015 - 07:10 PM

Specifically, it looks like you want this function, Ahmed.

#5212799 Is it time to upgrade to Dx11?

Posted by Ravyne on 24 February 2015 - 05:16 PM

Might want to hold off a bit if it isn't a major issue yet; DX12 will bring another major API shift and with Win10 going 'free' for anyone with Win7 or Win8 it could well get a lot of traction.


For very experienced developers, hobby or otherwise, I think this advice rings true. But I'm no so sure for less-experienced devs, or those who don't care about ultimate performance at the cost of dealing with the much-more explicit model of D3D12. I think ultimately there will end up being an "easy mode" API that puts the training wheels back on Direct3D 12 for those who want a simpler model and don't need unfettered performance, but as far as I've heard, no such thing is coming immediately, and Direct3D11.x will sort of serve that role in the meantime.


And as Hodgeman suggests, the best thing to probably do now is to use D3D11 in a way that prefers the constructs and patterns that'll stick around in the new world order.



That said, there's probably a balance to be struck, too -- We all know the hoops one must jump through in old-world Direct3D to make a scene look good in only a few thousand draw calls (and etc.), and I think there's a case yet to be made whether dealing with the newly-explicit threading models and synchronization issues (+more)of D3D12 are a greater or lesser headache than that in the long run. But at least for the immediate term D3D11 (and 9, even, if you want to target Asia) makes a lot of sense until everyone is on Windows 10, and that will give more-experienced, early-adopters of Direct3D 12 time to figure out what best-practices are for the less-experienced to follow.

#5212737 Getting Destroyed in Programmer Screeners

Posted by Ravyne on 24 February 2015 - 11:42 AM

just a couple general observations:


You really do need to be good at matrices and vectors. And at least have some familiarity with Eulers, concepts like gimbal lock, and quaternions.


Matrices and vectors underpin most of the kind of math you're going to encounter in everyday tasks -- you need to be able to scratch out some problems on the back of a napkin or whiteboard these things. Its not just about programming, its also about being able to communicate effectively with your peers.


Second, keep in mind that part of the way people evaluate you is to see where your limits are. One strategy for interviewing people is to just keep asking deeper and deeper questions until the candidate sinks. Its great if you can complete everything, and you should always make an attempt, but you probably shouldn't feel as though you have to solve every problem correctly before sending it back. But always show your work and thought process, even if you only get part way or come to the wrong answer; a wrong answer with reason is better than the wrong answer on its own, and its often no worse than the correct answer on its own (which right or not, doesn't tell anyone about how you solve problems).



Overall advice: These are not quizzes like you remember from school. The point is not to score 100%, its for the interviewer to attain insight into your skills, knowledge, working practices, and sometimes personality. Always try to have your positive traits shine through, even when you get stuck not being able to provide the correct answer. Most places would rather hire the humble, hard-working, but fallible human than the silent, unattainable genius.

#5212543 Help, how is this style of graphics made?

Posted by Ravyne on 23 February 2015 - 03:50 PM

Taking it one bit further, you really do want to go full-blown 3D with a fixed camera perspective and orthographic projection these days. Not only was the historically-accurate way of doing this simply difficult for the artists, but tall,large,and overlapping objects or paths were very, very painful to account for on the programming side -- not impossible, but needlessly difficult when the whole issue can simply be side-stepped today by using proper 3D. And it complicates everything, not just rendering -- pathfinding, collision detection, even the simplest of game logic becomes needlessly tangled in the old way of doing it. And as a bonus, when using the full 3D method, you get proper lighting if you want, so things like bump-mapping and parallax mapping and shadows all work seamlessly.

#5212542 blast a solid black circle

Posted by Ravyne on 23 February 2015 - 03:41 PM

By the way, one optimal approach that's easy to adapt to your current code structure would be to leverage the symmetry of the circle to fill entire horizontal spans all in one go.


In this approach, change the second for loop to for(int x = -radius; x <= 0; x++), and then instead of filling a single pixel at that point, fill the entire horizontal line between here and the matching point on the far side of the circle. The point on the far side has an x coordinate of (radius - x). To fill the horizontal line, you can another for loop inside your if statement that fills pixels, where you currently fill just one pixel, and then put a break; statement at the end of your if block to exit the x loop early.


Better still, though, would be to use an optimized span-filler that can write multiple adjacent pixels at once, but it might not make much difference for small circles. You'll get the biggest win by reducing the number of iterations and multiplies; the method I described above does that.

#5212539 blast a solid black circle

Posted by Ravyne on 23 February 2015 - 03:31 PM

google "Circle rasterization" for optimal approaches.


For a naive approach, loop over the entire area of the square that covers the circle you want (Your for-loops are right for this), and fill the pixel whenever its distance to the center of the circle is less than the radius (this is what your if-statement does, it appears correct).


Inside your if-statement, I assume that bullet.x and bullet.y transform the circle from its own space into the world-space, where the bullet is. And I assume that pixel offset is calculating the in-memory address of the pixel (again, this appears correct). But its not clear what the variable ptr is, I assume it to be the base address of the framebuffer. If that's the case, your error is here, because you're modifying it every time you do +=.


Instead of the last two lines, do *(ptr + pixelOffset) = 0xff000000; instead.

#5212535 Is buying assets cheating?

Posted by Ravyne on 23 February 2015 - 03:20 PM

Only you can determine for yourself whether you're cheating, according to your own terms. Unless you're competing in some kind of organized event, there are no such terms and conditions on what you're allowed to do and still call yourself a game developer, besides, of course, making games.


Anyone who claims otherwise is forwarding the no true Scotsman fallacy.

#5212494 Modern 8-bit game

Posted by Ravyne on 23 February 2015 - 12:54 PM

Its a fairly interesting question -- more interesting than just colors anyway.


The trick to making a game that has that nostalgic  8-bit feeling, really, is to be very true, or mostly true to the whole experience. For most people in North America, and many in Europe and Japan, the 8bit era was defined by the NES/Famicom, and so the answer really is "Do as the NES does" if you want to evoke the feeling of the authentic 8-bit experience in those people. In other parts of the world, the Sega Master System, which was in all ways technically superior to the NES, either dominated or made a more-even showing against the NES/Famicom -- In Central and South America, it thrived well into the SNES/Genesis Era (There are ports of street fighter 2, mortal combat, and Sonic 2, for instance, owing partly to the GameGear being essentially a portable Master System), and it made a stronger showing in Europe than it did in North America. For those people, the Master System defines the 8-bit experience.


But its not just the colors of pixels that makes the systems feel like they do -- its also the other limitations that game developers had to work around. If you don't follow through on those, your game might feel less like a 8-bit game, and more like a modern game with bad graphics and animation. For example, the NES only had memory for 64 sprite positions on the screen, and you could only have 10 of them on any given scanline of the screen. Sprites could only be 8x16 at the largest, too, so larger sprites (think Battletoads, or TMNT: The Arcade Game) consumed several hardware sprites -- when the bad guys flicker in an NES game, or the game slows to half-speed, its because of those limitations. Another limitation on the NES was that any given hardware sprite could only contain 3 colors + transparency. In the background graphics, something similar is true -- only 3 unique colors + 1 shared background color, and also all background tiles were 8x8 pixels, and the 3 unique colors were shared by every 2x2 group of such tiles. Similarly, most NES games didn't have very smooth animation because of limitations on how much graphics memory was available. Put all of these things together with the NES palette, and you will have a game that feels very much like an NES game.


But, you don't have to be totally accurate, either, there's no good technical reason today to have flicker or slow-down, so don't unless you have a design reason for it -- but, you also can't use that new-found freedom to make a game with 100s of sprites if you still want it to feel like an authentic retro game. Or, you might not care, or you might like to make a game that's a sort of unconstrained imagining of what 8-bit games could have been. Similarly, the NES color palette itself isn't perfect -- There's no good beige, no good dark red or purple, no vibrant orange. The guys who made Shovel-Knight took great pains to be authentic, going so far as to implement color-cycling in a modern GPU shader, but also added some of these colors I mentioned to their palette.


Let me end with a few resources:

Breaking the NES for Shovel Knight

The NES color Palette (NTSC)

The NES that Never Was...

How NES Graphics Work


DawnBringer's 16 color palette

DawnBringer's 32 color palette

#5212181 How do game engineers pack their data?

Posted by Ravyne on 21 February 2015 - 06:28 PM

To pile on, you're right that editor-friendly formats aren't a great idea, but its not because how easy they are to edit, its because editor formats are built for editing and don't have any concern about hitting soft-real-time requirements, or how small they need to be to suit disk-bound or digital distribution.


The ideal formats for AAA and very demanding games are minimal processing between reading and seating them in memory -- data should, per-platform, be read into its exact in-memory format, complete with proper padding, alignment, and data-representation, when possible (zero-out the padding, for security and better compressibility). That allows data to be round-tripped with no intervention in theory, in practice, you'll probably want to do a minimal amount of validation.


For games that aren't as demanding, typically digitally-distributed ones (Indie games typically fall into this category, though not all that do are indie), file size and simplicity are often better goals to strive for. For that, you'll probably want a binary file format that's a sequential representation of the in-memory format, but which removes padding and ignores alignment. Then, you'll probably want to compress the entire packfile or whatever with something like zlib. For some file types, like textures, that have specific, effective compression like DXT and friend, you'll want to do that before compressing further, or maybe use a scheme that only compresses files without specific compression methods.

#5211752 DirectX Vb.Net Installation

Posted by Ravyne on 19 February 2015 - 02:43 PM

C# really isn't any harder than VB.Net, IMO. VB.Net might look friendlier, but even before Microsoft officially committed to parity, C# and VB.Net have always been nearly identical, especially in the earlier days, before they started diverging. It has some ideas that kind of cut across the grain of most other languages (and so, libraries written for most other languages as well), like I think the default rounding mode for floating-point-to-integer conversion is "bankers' rounding" like is used in accounting, rather than the rounding as you know it like is used in math and science.


I remain somewhat convinced that the only reason VB.Net exists, when you get right down to it, is that none of Microsoft's corporate clients wanted to pay their VB6 programmers the kind of salary that programmers expect when they program a language that looks like C. Surely they didn't want pay to retrain them or port their existing software either, but at the end of the day that situation came to be in no small part because VB programmers were typically cheaper and more available than skilled C or C++ developers at the time, or even Delphi or Borland Builder programmers. I'm ranting now -- I have no love for VB -- so I'll stop; the short version is that I really don't think there's any reason for a new developer to learn or use VB.net today, unless they're planning a long, illustrious, and entirely dull career maintaining purchase-order software at some back-woods mail-order outfit. Tomorrows VB programmers are today's COBOL programmers.

#5211742 DirectX Vb.Net Installation

Posted by Ravyne on 19 February 2015 - 01:49 PM

In principle, if a library can be used with C# then it can be used with any .Net language -- the basic idea behind .net is that all the .net languages speak the same language underneath when they talk about data and function calls and stuff -- you can call a VB.Net function from C# and a C# function from VB.Net and everyone agrees about the data layouts and calling conventions, so it ought to go off relatively smoothly. But I also believe this takes a little work from the developer, because IIRC VB.Net has, for example, case-insensitive identifiers, while C# is case sensitive -- this can introduce some friction into the process.


So in essence I think it can always be made to work, but that doesn't mean that the developer has made any efforts to make the VB.Net experience as nice or easy as the C# one. That said, of all the .net languages, C# and VB.Net are most-alike (indeed, Microsoft are committed to language-feature parity between the two) and this should be the least strain on framework providers. Other .Net languages that are a more radical departure, say, F# or IronPython or others, take a lot more effort to make a framework that "feels" right in those languages (or you maybe wouldn't want to use them for the bulk of a game anyways). I know there are samples, though, where the UI and presentation of a boardgame are written in C#, but the AI is written in F# because functional languages are really a pretty good fit for that kind of thing.

#5211738 Hiding savedata to prevent save backup

Posted by Ravyne on 19 February 2015 - 01:29 PM

I'm in the camp that says its not worth your time to do something novel (some new kind of 'protection' scheme) or overly 'clever' (and disrespectful, like hiding files in unexpected places on a user's machine, especially silently).


If you must do anything at all, do something with standard tools and practices. Yes, the experienced cracker will get around this still -- the experienced cracker will get around anything you throw at them. So it follows that the best use of your time is to reasonably thwart the casual cracker (they kind who seeks out a save file and makes his or her own backup, or might open ASCII save files in a text editor and try to manipulate them) with a minimum of effort using standard mechanisms.


For example, if you put a binary-formatted save file into a password-protected.zip archive (and maybe that password is a hash of the user's "product key" or their registered email address, and named it something innocuous like "metadata_db.bin", no casual cracker would be likely to get around it. Anyone who has the skill to determine what you've done and extract the password scheme from your executable is not a casual cracker. Now, once even one real cracker takes an interest in defeating you, they'll probably release tools to automate the process if your game is at all noteworthy, and once that happens the floodgates are open to all, but at least the less-scrupulous players will have to seek out the crack tools first -- and I guess that if causing them that small inconvenience helps you sleep better at night, go ahead, just make sure the sleep you gain pays dividends to whatever time and sleep it cost you to implement the scheme in the first place.


[EDIT] Thinking about it more, even what I described, because of where the metadata_db.bin file would most likely be located this is still somewhat unscrupulous, because it wouldn't play well with the way that user might try to backup their data. To be a good citizen on your users machine, and you should always strive to be, you should put their save files in the place designated by their OS, not just next to where they happened to install it (this follows for user and global configs, screenshots you allow them to take, etc, too). For user configs and save files, this is well and narrowly defined, on something like linux, its well defined but I believe more broadly. On Windows, if you play by the rules of where certain kinds of data should go, a users can use the system backup and restore or migrate their user profile to another PC, or move their data to the newest operating system, and they should be able to expect that everything just works, even if they have to re install your game. You should try to make sure they're not disappointed. You can still put it in a password-protected zip file with an innocuous name if you like though (but the strange name probably less indiscreet here.)

#5211731 Am I wasting my time with this

Posted by Ravyne on 19 February 2015 - 01:03 PM

It might come down to whether you prefer to start from code at a somewhat lower level, or if you'd like more of the common stuff done for you and some (but not all) of it exposed through WYSIWYG-style editors -- XNA/MonoGame/FNA for the former, Unity for the latter. There's also Unreal Engine that's sort of a mix of both (as I understand), and there are other things like Cocoas-2D that are similar to an XNA-styled library. Or SharpDX/SlimDX for a very thin wrapper over graphics and multimedia capabilities.


I don't think any of these options are bad or represent a likelihood of wasting time. Whether or not any of these options are actively developed is somewhat of a moot point, so long as you can continue to publish your games and people can continue to run them. You might not be able to get a bug fixed, and that's a valid concern, but these things have been used in enough software that they must not be riddled.


I'm still getting to grips with Unity myself, and you do need to learn "the Unity way" in some sense, but on the other hand--and even though Unity provides a lot--you'll still find yourself pretty quickly limited with what Unity can do with the totally out-of-the-box experience, and you'll probably find that you need to delve into writing scripts and editor plugins sooner than not, or buy them from the asset store if you're so inclined -- just as one example, I'm working on a tile-based sprite game in Unity, and the tools and workflow that Unity offers, at least any that I've found, are not suited to the task terribly well, so essentially the very first thing I had to do after finding out how poorly suited Unity was, was to start writing a tilemap-loading script for Unity Engine and a tilemap editor plugin for Unity Editor -- but the experience of doing that has been relatively smooth: derive from a specific class, implement some methods, know a bit about when and why Unity calls those methods, learn how to use Unity's UI layout and control classes, and a few other little tricks found quickly via google -- My tilemap editor something like 350 lines of code, and while its nothing fancy, does a lot more than any 350 lines of code has any right doing. If you were doing something more closely-aligned to what Unity does well, like a 3D game or flash-style 2D game, you probably won't have to deal with editor plugins so soon, and do less scripting overall.

#5211711 DirectX Vb.Net Installation

Posted by Ravyne on 19 February 2015 - 11:20 AM

You probably want SharpDX instead, AFAIK, SlimDX isn't in development any more and, I think, isn't up to date with the latest DirectX. The developers of SlimDX lurk around here, so one of them might chime in, but I think I've seen even them recommending SharpDX over their own library, even. Otherwise, its a solid library, there's no specific harm in using it, its just older and less maintained than SharpDX I believe.


On the issue of installing and configuring third-party frameworks and libraries, I can sympathize that it can be difficult to figure out at first, especially if you don't have an example or someone to guide you. When I first tried to teach myself C (ages ago, now, when I was around 13) I was in the same boat and never did figure it out on my own, which kept my adventures in C limited to the text console. I moved to QuickBASIC which could do basic graphics on its own, and when I became comfortable in that environment but outgrew its inherent capabilities, I finally forced myself to figure out how to use the awesome and very fast assembly libraries that people had written. Once I had that, I didn't try to touch C again until I was in college. Anyways, my point is that you really should learn how to do it sooner than later, because it really opens up the world to you. I daresay that figuring out this basic skill is absolutely the best thing you could do for yourself right now.