|
brian posted:I wonder how many times this same discussion about striking a balance between doing stuff well and actually getting games done has happened in this thread, it must be once every 3 or 4 pages by now. "There are two types of mod: The best mod ever, and the one you can finish." I really don't like Mindcrime (he's an egomaniac), but if there is one line you want to remember when you're making a game, then that's it. As for "make games, not engines": The only way anybody will give a poo poo about your engine is if you proved you can finish a game with it. If you can't finish a game with it, it's a lovely engine anyway.
|
#
?
Jan 23, 2011 03:45
|
|
|
|
| # ? May 11, 2024 06:41 |
|
|
Pollyzoid and others posted:Even better solution would be using Console.ReadKey(), which reads only one key as input and returns more useful information. Thanks for the help everyone. I guess I will use either that and ConsoleKeyInfo() or Console.ReadLine() elsewhere when I need longer input. Will probably take some broken attempts before it's fixed, I'm not at the point where this looks easy yet (sometimes just remembering the proper syntax is like bashing my head against a brick wall). So yeah. Replacing the Console.Read with Console.ReadLine(), and using if (int.TryParse... Harmonica fucked around with this message at 04:08 on Jan 23, 2011 |
|
#
?
Jan 23, 2011 03:49
|
|
|
I've been trying to learn SDL for a while now, using the [url="https://"http://www.lazyfoo.net/SDL_tutorials/"]Lazy Foo Tutorials[/url] if you're familiar with them, but it's been slow going. I was checking out XNA recently and it looks a lot... cleaner. And easier. Is there any good reason NOT to use XNA and keep trying SDL?
|
|
#
?
Jan 23, 2011 05:54
|
|
|
Zero The Hero posted:I've been trying to learn SDL for a while now, using the [url="https://"http://www.lazyfoo.net/SDL_tutorials/"]Lazy Foo Tutorials[/url] if you're familiar with them, but it's been slow going. I was checking out XNA recently and it looks a lot... cleaner. And easier. Is there any good reason NOT to use XNA and keep trying SDL?
|
|
#
?
Jan 23, 2011 06:29
|
|
|
Zero The Hero posted:I've been trying to learn SDL for a while now, using the [url="https://"http://www.lazyfoo.net/SDL_tutorials/"]Lazy Foo Tutorials[/url] if you're familiar with them, but it's been slow going. I was checking out XNA recently and it looks a lot... cleaner. And easier. Is there any good reason NOT to use XNA and keep trying SDL? Do you want to make something that runs on Windows and Xbox only and use C#? Then use XNA. If you want to make something that runs on other platforms, or use a language other than C#, then use SDL. The only real use for SDL nowadays is as a cross-platform wrapper for initializing OpenGL (and simple input handling.) The tutorials you linked might teach you some relevant concepts but in terms of practical game programming skills they're over a decade out of date.
|
|
#
?
Jan 23, 2011 06:48
|
|
|
Paniolo posted:Do you want to make something that runs on Windows and Xbox only and use C#? Then use XNA. If you want to make something that runs on other platforms, or use a language other than C#, then use SDL. The only real use for SDL nowadays is as a cross-platform wrapper for initializing OpenGL (and simple input handling.) The tutorials you linked might teach you some relevant concepts but in terms of practical game programming skills they're over a decade out of date. Do you have any better tutorials? So far the tutorials have been great. They don't teach everything, but what they do teach they teach well, and quickly. As for language, I'll write in whatever language I need to. I had planned to write cross-platform for SDL, but if I end up using XNA, I don't mind being restricted to Windows. I've written in C/C++/Python/Java/C# and a bunch of other things. But I feel like C# is going to take over a lot of things because of its simplicity, so if XNA doesn't have any downsides except being stuck on Windows, I might just switch to it.
|
|
#
?
Jan 24, 2011 21:11
|
|
|
If you want some SDL tutorials written in an OO game development mindset, check out http://www.sdltutorials.com/
|
|
#
?
Jan 24, 2011 21:38
|
|
|
Zero The Hero posted:Do you have any better tutorials? So far the tutorials have been great. They don't teach everything, but what they do teach they teach well, and quickly. As for language, I'll write in whatever language I need to. I had planned to write cross-platform for SDL, but if I end up using XNA, I don't mind being restricted to Windows. I've written in C/C++/Python/Java/C# and a bunch of other things. But I feel like C# is going to take over a lot of things because of its simplicity, so if XNA doesn't have any downsides except being stuck on Windows, I might just switch to it. It's not that those tutorials are bad, it's that they're obsolete. Any graphics work (yes even 2D stuff) nowadays should be done using DirectX (which XNA is a wrapper for) or OpenGL; as I mentioned, SDL is great as a cross-platform initializer for OpenGL, but that's about it. I'd say you should go with XNA, there's a lot of good documentation available for it, and it uses modern graphics programming techniques. There's so much out of date stuff floating around for SDL and OpenGL (like NeHe) that a lot of people don't realize they're reading something out of the 90s.
|
|
#
?
Jan 24, 2011 21:46
|
|
|
Zero The Hero posted:if XNA doesn't have any downsides except being stuck on Windows It's been a long while since I've used XNA but the big downside right now seems to be that Microsoft wants it dead, or at least the PC side of it. Looking at the new website I can't even see any mention of Windows development, just the "app hub" crap. Last time I checked, the website seemed entirely devoted to those X360 avatar thingies and now it's all Windows Phone stuff. I don't want to put you off of using XNA, it can certainly be a great learning tool (I used it to teach myself shader programming a few years ago), but there seems to be no clear direction to the project. Could anybody who currently uses XNA tell me if they ever changed the way content processors work? Because recompiling the whole solution to see a texture you edited was silly. Have there been any useful additions/changes to the Windows side of things recently?
|
|
#
?
Jan 24, 2011 22:11
|
|
|
I'm kind of curious; I want to learn, and XNA came heavily recommended, but like Cray said they seem to have done their best to make sure you can't find any information on the PC side of things. I can't seem to find any useful information on using it for Windows; on a related note, it uses C#, doesn't it? Where could I find good learning material for that?
|
|
#
?
Jan 26, 2011 12:09
|
|
Break a leg!
|
Back in my XNA days ziggyware.com was a great source of tutorials but it appears to have croaked in 2009. Unless there's a mirror of it somewhere that's a ton of resources gone down the drain.  E: The Wayback Machine has some of it but it loads excruciatingly slow for me. Cray fucked around with this message at 13:03 on Jan 26, 2011 |
|
#
?
Jan 26, 2011 12:59
|
|
|
Chocolate Donuts posted:I'm kind of curious; I want to learn, and XNA came heavily recommended, but like Cray said they seem to have done their best to make sure you can't find any information on the PC side of things. I can't seem to find any useful information on using it for Windows; on a related note, it uses C#, doesn't it? Where could I find good learning material for that?
|
|
#
?
Jan 26, 2011 13:16
|
|
|
3DBuzz.com also has some decent tutorials for XNA/Unity/C#
|
|
#
?
Jan 26, 2011 17:32
|
|
|
Why would Microsoft try to kill the Windows side of XNA? They should have seen by Steam's success that PC gaming is very profitable, and with the extra work they've put into Games For Windows Live recently, it looks like they recognize this and want to capitalize on it. What sense would it make for them to try to restrict the only existing method that allows developers to develop for XBL and GFWL at the same time?
|
|
#
?
Jan 26, 2011 23:08
|
|
|
Zero The Hero posted:Why would Microsoft try to kill the Windows side of XNA? They should have seen by Steam's success that PC gaming is very profitable, and with the extra work they've put into Games For Windows Live recently, it looks like they recognize this and want to capitalize on it. What sense would it make for them to try to restrict the only existing method that allows developers to develop for XBL and GFWL at the same time? I don't think they're trying to kill it. I think they are trying to package Windows/XBLA/Windows Phone 7 development all into one "unit." They call it the App Hub and everything is stupidly addressed as mainly Windows Phone 7 stuff even though it applies across the board. I think it's mainly the result of poor marketing strategies.
|
|
#
?
Jan 26, 2011 23:26
|
|
|
That's the strategy they've been running for a while, though. One development platform that works on all of their poo poo. I like their strategy a lot, personally. But someone earlier in the topic said they were lessening support for the Windows side, or something, and it had me kind of worried.
|
|
#
?
Jan 27, 2011 00:39
|
|
|
Zero The Hero posted:That's the strategy they've been running for a while, though. One development platform that works on all of their poo poo. I like their strategy a lot, personally. But someone earlier in the topic said they were lessening support for the Windows side, or something, and it had me kind of worried. No I agree in that I love the approach. One package for all. It's just that now it's basically just labeled as Windows Phone 7 dev and it's hard to tell otherwise.
|
|
#
?
Jan 27, 2011 01:25
|
|
|
BonoMan posted:3DBuzz.com also has some decent tutorials for XNA/Unity/C# The Milkman Cometh posted:Aren't there tons of examples for pc at http://create.msdn.com/en-US/education/catalog/sample/winforms_series_1? And https://www.riemers.net doesn't look too bad either. I'm not seeing a lot for the most recent versions of Visual C# (the "XNA 101" series on 3DBuzz, for example, suggests you download Visual C# 2005, and the riemers stuff looks like it dates back to 2003, while the msdn link is just two very specific tutorials.) Will these still work with XNA 4 and Visual C# 2010? 
|
|
#
?
Jan 27, 2011 02:22
|
|
|
Within the AppHub link look at the 'find content by dev area' box - it links to a bunch of examples of stuff for XNA 4.0. The full version of 4.0 was just released within the last few months, so it's not unreasonable that there aren't a lot of 4.0-specific guides out there yet. The main changes they made in 4.0 were adding support for the new phone stuff, dropping the old Zune stuff, and changing around some of the graphics API to span the range of supported devices a bit more cleanly. If you're doing 2D games for Windows 99% of the stuff in the Reimers guide will be exactly the same as it was in 3.x. Get one of the new 4.0 books (Aaron Reed or Miller & Johnson are good) if you really want to dig deeper or do 3D. That said, I do think the XNA marketing team should be hauled out into the countryside and left to die in a ditch. They should be showcasing XNA as a multiplatform dev tool for Windows/Xbox/WinPhone, and not a WinPhone dev tool that happens to also support Windows/Xbox. The XNA platform is actually really nice to use and takes a lot of the drudge work out of common tasks that pop up in game dev, plus C# is just a great language to work with. If it only had a low-level wrapper around DirectX it would be nearly perfect. PDP-1 fucked around with this message at 03:38 on Jan 27, 2011 |
|
#
?
Jan 27, 2011 03:36
|
|
|
Chocolate Donuts posted:I'm not seeing a lot for the most recent versions of Visual C# (the "XNA 101" series on 3DBuzz, for example, suggests you download Visual C# 2005, and the riemers stuff looks like it dates back to 2003, while the msdn link is just two very specific tutorials.) Will these still work with XNA 4 and Visual C# 2010? This site has some XNA tutorials written in plain english, and he's in the process of converting them to 4.0, so they should be fine. They're pretty basic but enough to get you started http://rbwhitaker.wikidot.com/xna-tutorials and there's also a c# crash course on there too i think if you need refreshing.
|
|
#
?
Jan 27, 2011 20:35
|
|
|
I'm doing a simple tile based game in java and using LWJGL to draw it like. Once per frame I:
- Feed those tiles to my renderer - Renderer gets the color and texture coordinates of the tiles and draws them like this I've been reading some tutorials and playing around with vertex arrays (also deprecated) but trying to draw a 64x48 array of tiles with different texures&colors each with those just boggles the mind. I'm having trouble understanding any of that vertex buffer object stuff. Can someone with experience tell me how wrong my approach is and what's the 'right' way to do this tile stuff? Any helpful tutorials?
|
|
#
?
Jan 31, 2011 16:53
|
|
|
Elos posted:Can someone with experience tell me how wrong my approach is and what's the 'right' way to do this tile stuff? Any helpful tutorials? But if you're wanting to do it better anyway as a learning thing, a vertex buffer object is basically a vertex array that's stored on the graphics card so it's a lot faster. The only thing more complicated about it is that you have to lock it to write to it, and you're a lot better off not trying to read from it. Well, and, for edge cases and maybe not in Java, you have to be able to repopulate the whole buffer if it gets dropped for some external reason. So there's some management complexity, but not really any more *usage* complexity. However, you're saying that the vertex array is also too complicated? Can you draw two or three tiles with the vertex array? Because if so, drawing 3072 tiles is really no different! Though ideally you'd probably break it down into smaller blocks of tiles, like display-sized blocks, and only render the 4 blocks that intersect the screen. With 3072 tiles, much like with your original setup, you don't really need to add the complexity when it'll work fine to just render it all as one block of vertices mostly-offscreen.
|
|
#
?
Jan 31, 2011 17:14
|
|
|
I'm using SlimDX but I'm sure my problem applies to pretty much any framework: I am building a 2D sprite-based game. Floors, ceilings, walls, etc, are represented by quads. In the editor, I'm allowing two basic texturing modes for a quad: 'normal' (the texture coordinates go from 0.0 to 1.0, so it stretches) and 'fixed/tiled' (the texture coordinates are calculated depending on the size of the quad such that the tile repeats every 64 pixels, or whatever number is specified). This is all working fine so far, but I'm planning on introducing sprite sheets, which is going to make me pick out two specific texture coordinates as a 'source' rectangle, so my TU and TV picking strategy for 'fixed/tiled' mode won't work anymore. I'm sure this has been done before, can anyone point me to resources on solving this? It's almost like I want to specify source AND dest texture coords.
|
|
#
?
Jan 31, 2011 17:19
|
|
|
roomforthetuna posted:First, if it's running adequately the way you're doing it, you don't really need to worry about it. Performance improvements are for performance problems. roomforthetuna posted:However, you're saying that the vertex array is also too complicated? Can you draw two or three tiles with the vertex array? Because if so, drawing 3072 tiles is really no different! *snip* I'm thinking something like 1) Get the tiles that are visible on the viewport 2) If nothing has changed since last draw use the old arrays 3) If something's changed make new arrays out of everything on the viewport 4) Draw Should be a lot faster.
|
|
#
?
Jan 31, 2011 18:34
|
|
|
Elos posted:I'm thinking something like If you have things that move over the tiles, like a player-character, then ideally you want each of the sprites to have their own little [section of a] buffer, and move it around by changing the transformations rather than by changing the vertex coordinates. The goal when using vertex buffers is to change their contents as little as possible. (If someone knows better please correct me if I'm wrong on this!) In fact, if the tiles change a lot you might even be better off treating them as sprites (with permanent vertex buffer) rendered with transformations to the position of each tile rather than as one big vertex buffer that you change. (Again, confirmation or denial from someone who does performance stuff more than me?)
|
|
#
?
Jan 31, 2011 21:10
|
|
|
Don't use GL_QUADS, it doesn't work on some hardware. Use GL_TRIANGLE_STRIP with degenerate triangles if you want to do more than one quad per glBegin/glEnd pair.
|
|
#
?
Jan 31, 2011 21:19
|
|
|
This has been bugging me out all day, but I cannot get SFML 2.0 (or any version for that matter) working with Visual Studio C++ 2010 (Express). I've followed guides, I've followed videos, and every time something crops up that shouldn't have done and nothing ends up working. So does anyone have precompiled files for VC++2010? The ones that go in "lib" and "include" (I really need to learn more about the stuff that goes on before you get to the actual code). The more up-to-date (or version 2.0) the better.
|
|
#
?
Feb 1, 2011 00:17
|
|
|
Orzo posted:I'm using SlimDX but I'm sure my problem applies to pretty much any framework: Isn't a 'normal' quad just a special case of a 'tiled' quad where the texture is only repeated one time? A general draw call like DrawQuad(texture, sourceRect, destRect, xRepetitions, yRepetitions); could be used for normal quads as DrawQuad(texture, sourceRect, destRect, 1, 1); or for tiled quads as DrawQuad(texture, sourceRect, destRect, (destRect.p2.x-destRect.p1.x)/tileSizeX, (destRect.p2.y-destRect.p1.y)/tileSizeY);
|
|
#
?
Feb 1, 2011 02:20
|
|
|
The problem is that I don't know what function to call that actually takes a sourceRect and destRect
|
|
#
?
Feb 1, 2011 02:24
|
|
|
I don't know of a function that would do that directly, I think you'd have to write your own shader code. Off the top of my head, I'd pass the sourceRect and repetition counts into the shader as an extern variables and then turn the quad into a vertex buffer with position and texCoord info stored at each point. Write a texture sampler that maps from the sourceRect region onto the texCoords in the pixel shader with however many repetitions you want. The XNA SpriteBatch.Draw calls can handle source and destination rectangles, you can get their shader code here if you want to skim through it for ideas.
|
|
#
?
Feb 1, 2011 03:13
|
|
|
I think you might be slightly misunderstanding, XNA source and dest represent a source texture and a dest rectangle render target. Basically what I need is tiling from a sprite sheet, which I now know is impossible (from googling this issue) without the use of pixel shaders. Oh well, time to learn shaders!
|
|
#
?
Feb 1, 2011 03:43
|
|
|
can anyone point me in the direction of some good reading material for creating a procedural terrain/level generators?
|
|
#
?
Feb 1, 2011 03:48
|
|
|
Staggy posted:This has been bugging me out all day, but I cannot get SFML 2.0 (or any version for that matter) working with Visual Studio C++ 2010 (Express). I've followed guides, I've followed videos, and every time something crops up that shouldn't have done and nothing ends up working. You're having problems compiling? What's the issue?
|
|
#
?
Feb 1, 2011 12:11
|
|
|
boak posted:can anyone point me in the direction of some good reading material for creating a procedural terrain/level generators? If you're just starting. This might give you a nice jumping off point.
|
|
#
?
Feb 1, 2011 12:29
|
|
|
Caveat Postor: I'm not a render programmer by trade and I haven't used OpenGL for years, so I may have made some mistakes here.roomforthetuna posted:In fact, if the tiles change a lot you might even be better off treating them as sprites (with permanent vertex buffer) rendered with transformations to the position of each tile rather than as one big vertex buffer that you change. (Again, confirmation or denial from someone who does performance stuff more than me?) The downside of this is that your substituting lots of VB locks (which as you say is bad) with lots of draw calls (which is also bad). To make the code go faster the main goal is to reduce the number of draw calls (that is, calls to glBegin/glEnd), and reduce the number of times you edit/rebuild your vertex buffers. I'd suggest the following: 1) Merge all your tile textures into one single texture, and use U/V coordinates to specify which tile you want to draw in each quad. This will let you easily render multiple tiles from a single vertex buffer. 2) Divide your tile map into blocks, say 8x8 tiles, and build a vertex buffer for each chunk when the level starts up. The best block size is hard to guess, you need to balance between rendering as few blocks as possible per frame, and having blocks small enough that you don't waste too much time with rendering blocks that are mostly off screen. Try and set up your code so the block size is defined as a const/final value somewhere you can easily change and run tests to see what block size gives the fastest results. 3) Try building the vertex buffer using tri-strips instead of quads. As someone already mentioned, they're faster and more cross platform:  Edit: I have a horrible feeling that this layout won't work due to winding order issues, I always hated triangle strips  4) Give each block a "Dirty" flag. When a tile changes, set the dirty flag for its block to true. Then every frame: - Figure out which blocks are visible - For each visible block, check the dirty flag, if it's true, then rebuild it and clear the flag - Render each visible block Gerblyn fucked around with this message at 13:55 on Feb 1, 2011 |
|
#
?
Feb 1, 2011 13:40
|
|
|
not a dinosaur posted:You're having problems compiling? What's the issue? I never get four .lib files for each bit ( should be SFML-System.lib, SFML-System-d.lib , SFML-System-s.lib , SFML-System-d-s.lib, SFML-Audio.lib, etc....), and whenever I actually try to use the compiled files my project will crash when it comes to making a new sf::RenderWindow (in a manner which seems to be indicative of "You've got the wrong libs for your compiler version!" if the SFML forums are anything to go by).
|
|
#
?
Feb 1, 2011 17:30
|
|
|
Hey, I really want to get started in game programming, but I'm not sure what I'd like to use to make a game. I know the basic concepts of game programming, as I've played around with proprietary scripting tools and stuff before (like DarkBASIC several years ago), and I know C++ like the back of my hand, so I'd prefer to use that. I'd like to start with cross-platform 2D games, but I can't decide on what to use to make one. I've heard that SFML and SDL are good. Should I choose one of those, or is there a better choice?
|
|
#
?
Feb 1, 2011 23:17
|
|
|
I would say use SFML because it's got a more object-oriented design that you'll probably be more comfortable with if you're used to C++ rather than C.
|
|
#
?
Feb 2, 2011 00:35
|
|
|
boak posted:can anyone point me in the direction of some good reading material for creating a procedural terrain/level generators? So I've been taking a Programming in C class that I need for my math degree. My only prior experience with programming is a year of VisualBasic back in high school. Not much, but at least it was object-oriented. I've been picking C up really easily between random google searches and a copy of Kernighan-Ritchie, and I've been spending my time playing around with this and that while everyone else is trying to figure out scanf. I know that if I want to do something productive, I need to be using a language that supports OOP more than "just juggle structures for a few hours and then go open a vein." What's more, everything I'm doing now is written over PuTTY in vi on a Linux system that my school provides. I think the first thing I need to do is to start playing around in another language and to do it on my own system. So I think I need to choose between C#(which has XNA going for it), Python, and C++. Right now I'm interested in playing around with AI design, procedural generation, and simulation. I'm not concerned with people playing things I make and having fun, it's just to satisfy my own intellectual curiosity, really. I don't know if I'll move beyond that or not, but it's some place to start that will keep me motivated to learn more about programming. Can anyone straighten me out as to what direction I should be going in? Or things that I should be thinking about before I make any kind of commitment?
|
|
#
?
Feb 2, 2011 04:19
|
|
|
|
| # ? May 11, 2024 06:41 |
|
|
Anyone have a set of shader tutorials (DX9) that they found useful for 2D development? Mostly pixel shaders, since it's 2D I don't need much in the way of vertex shaders.
|
|
#
?
Feb 2, 2011 05:35
|
|