|
Danbo Daxter! posted:I am not interested in 3D games at all really, 2D is more my sort of thing. Are there any decent tutorials out there for using DirectX (or hell, OpenGL or some other graphics API) in a 2D context? Most of the ones I find seem to focus on 3D, and that seems like a gigantic branch of games development that I'ld rather not go near if I can help it. If you've already done some 2D programming with a 2D graphics library, feel free to disregard the next paragraph. I haven't seen any such tutorials myself, though they may very well be out there. If you're looking for a quick way to start, I'd suggest looking up some SDL tutorials, and going from there. For high-performance 2D, you'll still want to use Direct3D or OpenGL, but 3D libraries are significantly more complicated than straight 2D blitting libraries, in my opinion. To go ahead using a 3D library, if you can't find some good tutorials on using OpenGL or Direct3D for 2D display or a library that does it for you, the best way would probably just be to start with normal 3D tutorials. Once you've got a grasp on the concepts, it's pretty easy to just draw lots of screen-aligned polygons with an orthographic projection matrix.
|
#
¿
Dec 18, 2007 17:17
|
|
|
|
| # ¿ May 3, 2024 17:12 |
|
|
Wuntvor posted:ClanLib Wow, this sure has come a long way since I looked at it ~5 years ago, though still no version 1.0 (for whatever that's worth). I'll definitely have to look into it more when I get a chance, but if it's as good as you say, then this seems like a good choice for Danbo Daxter!
|
|
#
¿
Dec 18, 2007 22:29
|
|
|
Way back towards the beginning of all this multiprocessing discussion this came out,ehnus posted:Or if you really plan on going with a massively multithreaded system try a language/environment that's better suited for it, like... Stackless Python.... And I wanted to point out that it's a common misconception that Stackless Python in any way helps parallelism of processing. It doesn't. By not running threadlets concurrently, you can avoid all synchronization issues and with a little more work, you can even avoid deadlocks. So what's the point? Well, initially the idea was to add continuations to Python, although what's actually in Stackless turned out to be rather limited form of them, from my understanding. From what I can tell, the draw is that Stackless allows you to write code that calls into asynchronous functions in a manner that looks looks synchronous. As far as multiprocessing goes, the "Stackless" features of Stackless Python are pretty much orthogonal.
|
|
#
¿
Sep 15, 2008 18:35
|
|
|
Kleedrac posted:Where do I dig in? First thing is, put aside all your pseudo-code for classes you think you'll need. Figure out what the most bare-bones thing you possibly make that might still be remotely useful is, like say, a window that displays a picture. Now make it. Then start improving it really small ways, one feature at a time, by say, making that picture move in response to keyboard input. As the project gets bigger, make sure to take a little time to clean up old code when it's slowing you down, but don't get bogged down in major overhauls. Build tools, either in the engine or separately, only when doing so will actually save you time. Repeat until your magnum opus is complete. Basically, avoid working on speculation at all times. Make sure you're always working on stuff you need. Do this by taking baby steps and trying out what you've got. For more detail: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
|
|
#
¿
Nov 13, 2008 23:39
|
|
|
Look Kleedrac, pretty much everyone who's responding to you is right. I'm not going to restate what they said, but you would do well to read it again. You're talking about wanting to make more games down the line and so on, and you know what you should do? Forget about it. I'm serious. Don't think about any other games you want to make until this one is on its way out the door. Here's why: you'll be more likely to finish your first game if you aren't working on future games at the same time, and after you finish your first game, you'll be in an immeasurably better place to make decisions and judgments about how to make your second game. And the best news of all is that at that point, you'll have a working game to cannibalize for parts for the new game. You'll know what to rip out and what to reuse and how to reuse it. Oh, and just in case you think I'm being condescending: this is how we do it in the industry. Game engines are usually extracted from games, sometimes after reuse in many games. In the cases where one is written from scratch, there is a reason that it's done by the most experienced programmers in the industry. And as far as the window with the image not being a big part of what you're doing THAT'S THE GODDAMNED POINT! Do the smallest thing possible. Then do the next useful small thing. Repeat. You seem to have some belief that incremental development will not lead to clean or reusable design. This is what refactoring is for. On the contrary, your waterfall method will lead to a design that embodies your ignorance at the beginning of the process. So you're working with someone else? Well, one of you better get the project off the ground to the point where it's big enough you two can both work on different systems at once, and in the mean time, the other can work on some small tool that you absolutely will need (say, a map editor), but again, do so as simply as possible. Also, pay special attention to what MasterSlowPoke said about RPG Maker and Game Maker. It's a point I meant to raise, but if what you're most concerned about XP curves and all that, why would you spend time worrying about how sprites are blitted? People have done this before, and they've made good engines based on lots and lots of games that were built on top of them. Star Warrior X was right: the path you're going down right now is a path I've been down and I've seen many people go down, and there's no finished game at the end of it. Edited for clarity. Benji the Blade fucked around with this message at 21:05 on Nov 14, 2008 |
|
#
¿
Nov 14, 2008 18:06
|
|
|
tripwire posted:While its not that great yet, pypy is hopefully going to knock that door off its hinges by letting you translate your python code down to C, LLVM or CIL code. I'll try to keep this brief, since this isn't the Python thread. First off, I'm no PyPy expert, so feel free to correct me where I'm wrong. This is just gathered from some small amount of experience with it, and a bunch of reading. PyPy has a lot of promise, but PyPy is not particularly fast yet (unless that's changed really recently). PyPy can't translate normal Python into C, nor into any particularly fast form of LLVM, CIL, or anything else. What it can do is translate RPython, a subset of Python, into these things. The hope is, in the future, that it'll have a good JIT compiler/optimizer that will be able to do the same sorts of thing that the RPython translator does, but by generating the code needed on the fly, rather than using constraints to limit the needed permutations. Now, you could code your project in RPython, but (perhaps unwisely) the PyPy people didn't design RPython to be used outside of PyPy, and thus it doesn't really have a spec, and it apparently can be pretty cryptic and crash-prone, and it just isn't designed to be used outside of PyPy. You can use it, it just isn't recommended. I like Python a lot, and I think PyPy has a lot of promise, but I wouldn't encourage anyone to build games on top of it yet, and in general, I'm worried by the lack of real, immediately useful results from PyPy. However, the good news is that Pyrex/Cython is a really excellent way to generate C extensions for Python using something that feels like a pretty natural extension of Python. And there are lots of other good ways to call into C extensions, like Ctypes and SWIG, depending on your needs.
|
|
#
¿
Nov 25, 2008 16:13
|
|
|
Assuming you're looking to set the background of the contents of your pyglet window (that is, draw the background of your OpenGL context a certain color), see glClearColor and glClear which can both be found in pyglet.gl.
|
|
#
¿
May 14, 2009 15:32
|
|
|
If it makes you feel any better, I got into the game industry as a programmer straight out of college with my liberal arts BA (Media Studies). I worked programming jobs throughout college, and had some good projects to show from those jobs and from advanced classes I took, which, along with a connection or two, got me in the door. To those of you currently at Full Sail: make the most of your projects. I don't really know how teams are formed or whatever, but if you have any hope of making your projects good, do it, even if it means carrying the whole team. If that's unreasonable, you'd best start working on something on the side.
|
|
#
¿
May 21, 2009 14:38
|
|
|
Vinterstum posted:Very few open source projects are ever "finished", so that's not something people should be expecting Star Warrior X posted:The things that, to me, make any sort of independent (non-funded) project, whether school-related or not, stand out are polish and coherent, distinctive style. This is one big problem with open-source games. The number of open-source games I can consider to be polished and distinctive is vanishingly small. Not that opening up the source code leads to incomplete and/or crappy games, but the open source community isn't, generally, going to make your game better (except maybe at the level of infrastructure and libraries). I'd much rather see someone who made a cool little original game and finished it than someone who contributed to a large game project that will be perpetually in development.
|
|
#
¿
May 26, 2009 17:52
|
|
.
|
|
| # ¿ May 3, 2024 17:12 |
|
|
YourNakedUncle posted:On that note then, how do games that are classically animated, like Castle Crashers, or Elysian Tail get away with it? I could be off-base here, not having seen Castle Crashers' sprite sheets, but I think they probably use about half as many animation frames as you're using. Unless really smooth animation is key to the game/visual experience of your game, I'd try setting up a test where you skip every other frame while animating, and see if you think you can get away with that (with some slight tweaks to the animation cells rendered), at least for some characters, if not all. I'm also not saying 50% is a magic number or anything, but it should be easy to test with 50% by doubling frame time and skipping every other frame, and it should give you an idea of it's a feasible direction. Other than that, just what other people said: texture compression should take care of a lot of the extra transparent space and separate pieces out where it makes sense. Good luck!
|
|
#
¿
Oct 8, 2009 16:57
|
|