|
General_Failure posted:No VMs, seriously? I thought they removed that restriction. Of course, you still can't release a JIT (or anything that marks memory as executable), since that's a huge security leak.
|
#
?
Jul 15, 2012 08:05
|
|
|
|
| # ? Jun 13, 2024 05:56 |
|
|
OneEightHundred posted:I wish it was more like the commercial landscape where there's middleware that can do practically anything, but apparently everyone wants to make rendering tech and nobody wants to make the things that haven't advanced in 10 years. Tools like Spritely, DAME, etc just flat out didn't exist back in the day. If I wanted to make a tile based map? I made my own editor. Heck, anyone remember Garry who used to post here (you know, who made GMod)? The first few versions of his Facepunch side scroller used freaking MS Paint as a level editor, with the BMP format encoding tiles... and that wasn't even that long ago. I feel like right now, you're in a much better position to make a simple 2d game running on barebones tech than you were 5 years ago. Unfortunately, we're still lagging on 3d map editing tools, or even 2.5d side scrolling tools. Never even mind the hideous state of affairs for 3d modeling (Blender... ugh - though it is improving). If platforms cool off in the next few years, and so long as the target tech for games (3d, probably not much more than normal maps for indie level stuff, etc) stays stable, the tools should catch up and make it a pretty decent environment for engine makers again. Then we'd be back to the indie engine environment where people making stuff for fun might get bought out by one of the big names. I feel like open source tools aren't bad, they just lag behind the market, making them less and less viable the faster the market is shifting. As it stands, though, the amount of tech you have to build to be viable on the various platforms to such a level as to be noticeable is... substantial.
|
|
#
?
Jul 15, 2012 18:14
|
|
|
Shalinor posted:Heck, anyone remember Garry who used to post here (you know, who made GMod)? The first few versions of his Facepunch side scroller used freaking MS Paint as a level editor, with the BMP format encoding tiles... and that wasn't even that long ago. I still do that sometimes for prototypes because it just makes it really easy to quickly make and load tilemaps.
|
|
#
?
Jul 15, 2012 23:53
|
|
|
I sure wish I had made this project with something other than XNA from scratch, because now that I finally have a solution for collision that works just the way I want it to, I ran into another problem. This time it's about colliding with other objects, like NPCs. The way I do the collision resolving there is this, (it's a 2D top-down tile-based game) code:I don't know how to do the world check when doing this correction, it WOULD be taken care of by the other world check, but that only checks for collision when the object (player, NPCs, etc.) is moving (that is, when it isn't pushed), and only in the directions the character is moving. I am just about running out of ideas, any help and advice would be appreciated.
|
|
#
?
Jul 16, 2012 04:17
|
|
|
Bocom posted:I sure wish I had made this project with something other than XNA from scratch, because now that I finally have a solution for collision that works just the way I want it to, I ran into another problem. This time it's about colliding with other objects, like NPCs. Didn't get to talk to you about this last night, but think about it. Instead of setting positions, just set velocities to get to those positions. That way if a position's in a wall, it'll still collide with the walls correctly.
|
|
#
?
Jul 16, 2012 05:35
|
|
|
Shalinor posted:I feel like open source tools aren't bad, they just lag behind the market, making them less and less viable the faster the market is shifting. The problem is that nobody seems to want to make content creation tools that target some generic format that could be used in a lot of things, they only seem to want to make tools if they make editing some existing thing easier. Bocom posted:The way I do the collision resolving there is this, (it's a 2D top-down tile-based game)
|
|
#
?
Jul 16, 2012 06:06
|
|
|
OneEightHundred posted:Not sure I understand the scenario. This is for when an object is pushing another object, and you're trying to prevent the pushed object from penetrating? Or is the problem that an object that collides with several objects in a frame being pushed into a solid by cumulative corrections? Or something else? This, essentially. Walk into NPC -> Collision resolution -> If you're colliding at an angle near a wall, you're pushed into it.
|
|
#
?
Jul 16, 2012 10:33
|
|
|
You could probably check to see if the position your object is about to get pushed into is valid. If it isn't, don't do the collision resolution for it and relay back to the object doing the pushing saying "no, you can't move/push here".
|
|
#
?
Jul 16, 2012 11:54
|
|
|
Bocom posted:This, essentially. First of all, as someone else mentioned, don't "push", zero velocity so they can't make the illegal move in the first place. Switching from XNA won't help with this issue either, it's a valid, difficult, issue. It'll be taken care of for you if you use someone's framework but if you want to produce "your own" game - its not impossible to figure out. I'd recommend a series of bounding points, for world collision. Using radiuses will not allow you to move smoothly along a wall, you'll get tucked into corners between tiles. Use a series of points to test collision and do not use corners (since this will lead to sticking problems). Ive used two points per edge, offset inward by a few pixels, tested directionally in the past.
|
|
#
?
Jul 16, 2012 12:32
|
|
|
Generally what you want to do isn't push the player out of objects they're colliding with, you want to limit the movement for that frame to an amount that won't cause them to penetrate the object. This means you should check every object in their way for that frame and take the result that produces the least amount of movement. If you want to continue moving, i.e. sliding along the collision normal, you can do it from that position using their remaining movement for that frame. Circle-circle collisions can be reduced to point-circle by enlarging the other sphere's radius, at which point you can easily get the collision distance by just intersecting the line with the circle. Box edges collisions can be handled as point-to-line-segment checks, which are really just point-to-plane checks with a range check. For axially-aligned boxes it's even easier because then the point-plane collision is just subtraction.
|
|
#
?
Jul 16, 2012 14:10
|
|
|
ZombieApostate posted:You could probably check to see if the position your object is about to get pushed into is valid. If it isn't, don't do the collision resolution for it and relay back to the object doing the pushing saying "no, you can't move/push here". superh posted:First of all, as someone else mentioned, don't "push", zero velocity so they can't make the illegal move in the first place.
|
|
#
?
Jul 16, 2012 14:36
|
|
|
Orzo posted:These solutions don't work unless you're processing movement pixel by pixel--otherwise your game will feel blocky and clumsy, because you'll be in a situation where let's say you want to move a character 5 pixels to the right and you can't because there's a collision 3 pixels away. The correct behavior is to move the object 3 pixels according to the collision resolution, instead of just stopping the object. This is how my world collision works when you're walking around. I'm not actually using radii for world collision, I cast rays to determine how far away a collision is (the rays are the same length as the velocity) and move according to the result. The way I check if the collision radii overlap/collide is shown here. (Center returns a Point) So yeah, the problem is that I don't really know what to do from there. I can get them to not run through each other (even though setting position isn't the most elegant solution) but Not actually make it respect the world collision. Everything I've tried thus far just doesn't work very well.
|
|
#
?
Jul 16, 2012 15:35
|
|
|
Orzo posted:These solutions don't work unless you're processing movement pixel by pixel--otherwise your game will feel blocky and clumsy, because you'll be in a situation where let's say you want to move a character 5 pixels to the right and you can't because there's a collision 3 pixels away. The correct behavior is to move the object 3 pixels according to the collision resolution, instead of just stopping the object. That is quite correct! Especially with time based movement instead of pixel based movement, different dts would have you bouncing around if movement just stopped. Moving the correct amount to the collision point is the right way to go.
|
|
#
?
Jul 16, 2012 18:16
|
|
|
Unormal posted:This is sweet. You should wrap it up as a unity extension and sell it on the unity asset store. (With a package of YUV shaders)
|
|
#
?
Jul 16, 2012 20:12
|
|
|
OneEightHundred posted:Oh and regarding this, I'm going to port the whole thing to .NET just 'cause, so you'll get it in the free version after all. Yes, .NET! I approve of this idea. :.net: 
|
|
#
?
Jul 16, 2012 20:25
|
|
|
Hey guys - For the last week I've been making a GUI front end for the LibNoise perlin noise library. If you use perlin noise to make height maps or textures, try out my tool and tell me what you think. I use a lot of heightmaps in my projects, and I was tired of having to twiddle code all the time to manipulate the heightmap generator. I wanted some way to see the effects of different settings, so I made this. The download is availble on github: https://github.com/MadoxLabs/NoiseTool/downloads The instructions can be found at https://github.com/MadoxLabs/NoiseTool/wiki If you don't want to read them, you should at least know that there is a pullout menu on the bottom of each window, and right click parameters to make them type-ins. Please tell me of any bugs/feature requests or enter them on github. Here is a sample image: http://i.imgur.com/w6sOn.jpg
|
|
#
?
Jul 17, 2012 16:00
|
|
|
Madox posted:Hey guys - For the last week I've been making a GUI front end for the LibNoise perlin noise library. If you use perlin noise to make height maps or textures, try out my tool and tell me what you think. Your timing couldn't be better. I just started looking into libnoise for my terrain editor. I will have to wait till I get home to try this out, but from the screenshots and docs it looks good.
|
|
#
?
Jul 17, 2012 17:49
|
|
|
Apparently SetPixel is the slowest function on the planet. Anyway, hard part's done! 
|
|
#
?
Jul 17, 2012 18:35
|
|
|
Madox posted:Hey guys - For the last week I've been making a GUI front end for the LibNoise perlin noise library. If you use perlin noise to make height maps or textures, try out my tool and tell me what you think. Thank you so much for this! Definitely going to be using this very soon and frequently.
|
|
#
?
Jul 17, 2012 19:28
|
|
|
OneEightHundred posted:Apparently SetPixel is the slowest function on the planet. Hey I just read back to see what you are talking about. I'd be very interested in a c# version of an mpeg player. I wrote my own AVI library because it looked easier, but I can definitely use an mpg library.
|
|
#
?
Jul 17, 2012 19:36
|
|
|
Any opinions on MyGUI? It looks like the most appealing option I can find that's actually still being worked on. I know there was a lot of talk of "just use Unity/UDK", but I'm kind of  and I'm half way to something workable already, soooo...
|
|
#
?
Jul 17, 2012 20:41
|
|
|
ZombieApostate posted:Any opinions on MyGUI? It looks like the most appealing option I can find that's actually still being worked on. I know there was a lot of talk of "just use Unity/UDK", but I'm kind of
|
|
#
?
Jul 17, 2012 22:25
|
|
|
OneEightHundred posted:Apparently SetPixel is the slowest function on the planet. Yes. Yes it is. A few years back I was just stuffing around with the idea of a side on terrain generator by putting random pixels on the screen and having them fall into place then flow. Simple huge array, scanning through it. terrible way to do it but it was just an idea. I believe I used SDL SetPixel. Ohgod  I have never seen anything work so slowly. That idea was abandoned for a few reasons. Not worth the effort to pursue especially because it was just a silly test.
|
|
#
?
Jul 17, 2012 23:12
|
|
|
Shalinor posted:There's also Crazy Eddie's GUI (CEGUI), which is what I used last time - and seems to still be actively worked-on. Yeah, I saw CEGUI, but everything I've read about it seems to say it's a bitch to work with, and those sample screenshots make my eyes bleed. What was your general impression of working with it?
|
|
#
?
Jul 17, 2012 23:35
|
|
|
ZombieApostate posted:Yeah, I saw CEGUI, but everything I've read about it seems to say it's a bitch to work with, and those sample screenshots make my eyes bleed. What was your general impression of working with it? EDIT: Some examples from the casual game we made, way back when (those are 9-sliced windows with nicely tiling edge foliage with the transitions covered by the leaf caps in the corners):   It's definitely a programmer's UI, in that I spent a ton of time tweaking massive XML files. If MyGUI is reviewing better, definitely go for it. CEGUI works, and is powerful, but I wouldn't necessarily recommend it over anything else - just that it's still around and being developed / an option to consider. EDIT: And man, it is surreal to play that now. It still exists, on the internet, and it still works fine and looks pretty decent. We soooo overshot the hardware of casual gamers back then. Shalinor fucked around with this message at 23:52 on Jul 17, 2012 |
|
#
?
Jul 17, 2012 23:39
|
|
|
Heh, well, that's definitely proof that CEGUI can look nice if you try 
|
|
#
?
Jul 18, 2012 00:11
|
|
|
OneEightHundred posted:Apparently SetPixel is the slowest function on the planet. It really is. I'd actually be curious to see what the hell they are doing under the hood that makes getting/setting that little data take so long. If you haven't figured it out already, there are a couple of ways around using the slow functions that let you treat the image data as an array of bytes so you can read/write the values directly.
|
|
#
?
Jul 18, 2012 00:48
|
|
|
Shalinor posted:There's also Crazy Eddie's GUI (CEGUI), which is what I used last time - and seems to still be actively worked-on. I've heard good things about librocket, which is based on HTML and CSS, which coudl make things easier if you're familiar with those.
|
|
#
?
Jul 18, 2012 01:01
|
|
|
PDP-1 posted:It really is. I'd actually be curious to see what the hell they are doing under the hood that makes getting/setting that little data take so long. e: Anyway it's done, including audio, and it's on Google Code. Fixed the stupid audio bug after spending 4 hours tracking down one errant keypress, and straightened out the copyright nonsense. OneEightHundred fucked around with this message at 07:23 on Jul 18, 2012 |
|
#
?
Jul 18, 2012 02:46
|
|
|
Cream_Filling posted:I've heard good things about librocket, which is based on HTML and CSS, which coudl make things easier if you're familiar with those. In my experience, librocket's documentation kinda sucked. Which was disappointing, because it seemed like it might be a cool system. Perhaps that's improved since then, though.
|
|
#
?
Jul 18, 2012 04:37
|
|
|
I have been wondering how network latency is handled in games. Well not just games, but applications in general. I have a feeling that game engines have probably best solved this sort of problem, that's why I'm asking here. I can imagine a lot of scenarios where "a piece of data" is basically de-synchronized by latency, but I can't really imagine any good ways to solve that problem. Who can point me to some good info?
|
|
#
?
Jul 18, 2012 21:38
|
|
|
My Rhythmic Crotch posted:I have been wondering how network latency is handled in games. Well not just games, but applications in general. I have a feeling that game engines have probably best solved this sort of problem, that's why I'm asking here. I can imagine a lot of scenarios where "a piece of data" is basically de-synchronized by latency, but I can't really imagine any good ways to solve that problem. Who can point me to some good info? It totally depends on the type of game. A combination of prediction and really just the server having the final say is what helps. I mean it's a poor example of how to do it but ever played the battlefield games? When the connection gets laggy weird things start to happen. A little bit of lag and it tries to rubber band you back to where you should be. The server isn't going to accept your state because that could easily be exploited, and would leave the players in an unknown state. Add more lag and the other players appear to move like chess pieces. What you see as rubber banding for yourself is the same as the static coordinate relocation going on for them. No velocity or anything. Just various state specific things, position and heading. Again if this weren't the case it'd be chaos. It's all in the name of synchronization. By the same token in any network game with projectile velocity I've found my accuracy goes way up if I estimate where the other player should be based roughly on latency. So really it's not exactly handled. The client is sending requests to the server and the server is sending updates to the client. About all that can be done is a bit of guessing on the client side to try and keep things looking smoother, but try and stretch that out very much and it all falls apart, like the chess pieces and rubber banding.
|
|
#
?
Jul 18, 2012 22:00
|
|
|
My Rhythmic Crotch posted:I have been wondering how network latency is handled in games. Well not just games, but applications in general. I have a feeling that game engines have probably best solved this sort of problem, that's why I'm asking here. I can imagine a lot of scenarios where "a piece of data" is basically de-synchronized by latency, but I can't really imagine any good ways to solve that problem. Who can point me to some good info? UDP, UDP, UDP http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
|
|
#
?
Jul 18, 2012 22:11
|
|
|
There are a few ways to handle latency, but they are ALWAYS tradeoffs, in that any improvement in responsiveness come at the expense of jarring error corrections and the relative times and locations of things being incorrect. One of the big ones is prediction. I'll give a quick rundown of how Q3 does it: Clients in Q3 store a backlog of inputs that the client has made. The client will record the player's input and perform a limited simulation of what would happen if the player moved during that period. This includes colliding with objects, picking up items, firing your weapon, etc. When the client receives an update from the server, that update is of a time point in the past. What happens then is that the client will replay all of their old input from that situation to generate a new state, thus correcting any differences. One other factor is the predictable event list. Some transient events like the weapon flash are predictable, but could also be authorized by the server. What happens during the player movement stage is that those events are recorded in the predictable event list, which is a ring buffer combined with a sequence ID that iterates upward each time an event occurs. When the client finishes predicting a player action, it will check for any new events and fire them. When the client receives an update from the server, it will receive the event list and sequence ID that the server thinks it had at that time, and add any new events that occur as it replays its steps for correction. It then goes through that list starting at the sequence ID from the PREVIOUS update (to include things that happened between that update and the just-received one) and compares it to the old list. If there is a mismatch, then it means a new event happened due to a prediction change or due to the server causing a new event, and any events in the list from that point on will be fired. There are additional things you can do. Some games will cause actions with an animation time (i.e. armor lock in Halo games) to cut the animation time short on the server so that players can react to things in time. Another big thing is reconciling time differences between what the player sees (which is in the past) and where the player thinks they're aiming (which is in the present, and won't happen on the server until the future). Most games these days will store location histories of important things so they can reconstruct the shot at the time the player thinks they fired, leading to getting shot around corners, but not having to lead for latency. OneEightHundred fucked around with this message at 00:25 on Jul 19, 2012 |
|
#
?
Jul 18, 2012 23:40
|
|
|
Just here to have a bitch. Just tried compiling a playaround program I did with SGE in ...err, Ubuntu, Mint, or LMDE. Don't remember, with Code::Blocks. Encountered the usual issue with getting anything that works with SDL to actually function. I found what magic settings it wanted this time but the irritation of needing to fiddle the includes and linker settings every so often shouldn't happen. it doesn't with any other libs I know of.
|
|
#
?
Jul 19, 2012 00:06
|
|
|
General_Failure posted:Just here to have a bitch. Just tried compiling a playaround program I did with SGE in ...err, Ubuntu, Mint, or LMDE. Don't remember, with Code::Blocks. Encountered the usual issue with getting anything that works with SDL to actually function. I found what magic settings it wanted this time but the irritation of needing to fiddle the includes and linker settings every so often shouldn't happen. it doesn't with any other libs I know of. Are you unable to use sdl-config to get the correct settings for some reason?
|
|
#
?
Jul 19, 2012 05:00
|
|
|
prolecat posted:Are you unable to use sdl-config to get the correct settings for some reason? I have never, ever heard of that until you mentioned it. Thank you for that. The issue that plagues me is depending on computer with the includes it can be "SDL.h", <SDL.h> or <SDL/SDL.h> That sort of thing. And depending also sometimes the paths need to be added. This time "SDL.h" was the magic combo along with the linker stuff, which should have already been there anyway, and needing to add SGE to the linker which I didn't have to do last time. I swear it's only SDL that's like this. Anyhow I'm in the process of shuffling back across from the netbook the projects I managed to save when the desktop hard drive failed. I already have at least 90% of it backed up anyway but it's scattered over a lot of discs. Okay except about 10 years worth of stuff which somehow was destroyed. Originals and backups. I'm referring to the stuff after that. There would appear to be a couple of design outlines on my netbook. Might have to reassess them.
|
|
#
?
Jul 19, 2012 05:46
|
|
|
You stick $(pkg-config sdl --cflags) in your $CFLAGS and $(pkg-config sdl --libs) in your $LDFLAGS and you #include <SDL.h>.
|
|
#
?
Jul 19, 2012 10:07
|
|
|
I usually make all my games in either Python + Pygame for small projects/engines, or XNA for other stuff (I'm talking about 2D games here for both of these); but recently I've been getting annoyed at the lack of shaders and the general speed, and wanted to get into something a little more market-friendly. Dustforce and La-Mulana were both made with DirectX, and some other games I've seen have been made with OpenGL, and I really want to figure out how to make 2D games in OpenGL or DirectX. They're both things I just.. never got around to forcing myself to learn, because I don't really enjoy 3D gamedev (and if I do I use UDK). I know C#, Python, C++, and Java (In that order of how proficient I am with the language) mainly for gamedev, and I want to know how I can get started with 2D gamedev in DirectX/OpenGL, since it should in theory allow me to make games with nicer particles + shaders, faster calculations, etc. I've looked around and can't really find much resources or help on how to make 2D things with them though, only 3D. Any help/recommendations? (Also PM me if you'd like t'chat over Aim/Steam/Skype instead of in the thread for easier conversation)
|
|
#
?
Jul 19, 2012 11:51
|
|
|
|
| # ? Jun 13, 2024 05:56 |
|
|
Jewel posted:I usually make all my games in either Python + Pygame for small projects/engines, or XNA for other stuff (I'm talking about 2D games here for both of these); but recently I've been getting annoyed at the lack of shaders and the general speed, and wanted to get into something a little more market-friendly. Dustforce and La-Mulana were both made with DirectX, and some other games I've seen have been made with OpenGL, and I really want to figure out how to make 2D games in OpenGL or DirectX. They're both things I just.. never got around to forcing myself to learn, because I don't really enjoy 3D gamedev (and if I do I use UDK). I know C#, Python, C++, and Java (In that order of how proficient I am with the language) mainly for gamedev, and I want to know how I can get started with 2D gamedev in DirectX/OpenGL, since it should in theory allow me to make games with nicer particles + shaders, faster calculations, etc. 2D in directx is poo poo easy. It's been a while but I still remember being able to bash out a functional game-like program in a few hours. OpenGL is somewhat harder for 2D. I mean you could just have a small offset in the z axis and use billboards like sprites, or you could write 2d stuff to an openGL texture, or you could use SDL and write some OpenGL stuff to an SDL surface. I'm not sure but I think you can do the reverse too. Don't quote me on that. if you want to do 2d, OpenGL may not be the best tool. It really depends on how you tackle it, but there are many many options.
|
|
#
?
Jul 19, 2012 12:44
|
|