|
I have a DirectInput question - when I "EnumerateObjects" on a gamepad device, the controls returned are named:code:Is there some way a gamepad can be set differently within DirectInput before I enumerate its controls, so it won't assume it's for a flying game or whatever the hell it's doing, and will just treat its controls as the generic things they are? I would expect a control to be GUID_RzAxis only if it's a forward-facing twist-control, because that's when the control itself is a rotation around the Z-axis - I don't want my controller to be telling me that it wants me to be using an X-axis as a Z-axis-rotator. I don't like its name being 'rudder' either - when I put control names in the configuration box, how is a player going to know that the X-axis of their second joystick is called 'rudder'? That's pretty unintuitive. (Note: not using the action mapper at all.)
|
#
¿
Jul 18, 2010 17:41
|
|
|
|
| # ¿ Apr 28, 2024 01:02 |
|
|
code:(Since you're not talking C, I should specify that | is a "bitwise or" and could be replaced with plus in this context if you'd rather.) You might actually want fewer tiles since, eg. diagonal adjacencies aren't relevant if you don't have both the horizontal and vertical in that direction. But it's easier to just have 256 and make irrelevancies look like duplicates of the closest relevant type. Also bear in mind you need to make sure there's a buffer around the edges of the map so you don't end up checking coordinates of -1.
|
|
#
¿
Jul 25, 2010 00:41
|
|
|
And if you're rendering with DirectX or OpenGL or anything like that, you need even fewer actual graphical tiles since you can just have 10 actual tiles (corner, straight, T, dead end, lot, lot corner entrance right, lot corner entrance left, lot side entrance, lot corner, lot side), and rotate the texture coordinates for the different directions. Edit: or even 9, because the lot corner entrance could be flipped as well as rotated.
|
|
#
¿
Jul 25, 2010 17:10
|
|
|
Bitfields are fantastic for collision detection and physics, but horrible for pathfinding. For the purpose of a Worms-style game, bitfields are fine because you really don't need the AI to pathfind - you could probably just test-fire 50-odd randomly aimed imaginary shots and go with the best one. (More or less depending on the AI skill level, but testing 50-odd parabola on a modern computer would be near enough instant, and would already make a tough opponent.) The only concern then would be having the AI walk/swing/whatever competently. If I was doing this, I'd surely do it with bitfields. (Also you could speed things up similar to OneEightHundred's quadtree but more simply [and correspondingly less effectively], by doing a mipmapping of your bitfields - but I really don't think it would be worth the extra effort unless your maps are so big that bitfields wouldn't be a good method anyway, which would be pretty big.) Another way you could do it (which I've used for a different purpose), which might be better for very large maps, is with boundary-lines (run lines clockwise so a west-to-east line is 'floor' and an east-to-west line is 'ceiling') and some sort of sorted links to the lines so you're not constantly checking against everything (I used a loose grid where each square of the grid links to the lines that pass through that square). The coding involved in doing it that way is loving horrible compared to the simplicity of bitfields, though, and in most cases it's worse for pathfinding and worse for, well, pretty much everything except space. Also of note - if your displayed maps are made of an image then you may not even need (or want) separate bitfields for collision detection, you can just check against the displayed map pixels - I believe it's faster to compare "is DWORD (y*width+x) of the image my transparent color" than to compare "is bit (x&31) of DWORD ((y*width+x)/32) of the bitfield set". (If the display map is solely in video RAM this is a bad idea - but if you're wanting to arbitrarily remove pixels whenever there's an explosion then you'd be wanting a copy in system RAM for that editing anyway, so you might as well be keeping a copy in system RAM the whole time so that a change only has to copy it one way.)
|
|
#
¿
Aug 11, 2010 05:43
|
|
|
roomforthetuna posted:Another way you could do it (which I've used for a different purpose), which might be better for very large maps, is with boundary-lines [...] But seriously, if you can do what you want with your bitfields or pixel-checks, do do it that way, because it is at least one and a half metric fuckloads easier.
|
|
#
¿
Aug 12, 2010 03:37
|
|
|
quote:My problem is that I'm absolutely terrible with (OO) design and I usually either A great design is great and all, but at some point you just have to suck it up and work with/around the flaws that turn up in your design as you go. The art is in corectly determining when that point is. I've found that, for me, the design 'pattern' that works best is to structure everything like a tree - I have a "game" object that contains everything else related to the game contents, and an "engine" object that contains all the DX/whatever functions and object management. Within 'game' I have a 'screen' that contains all the features of a menu screen or game screen (the screen pointer changes to a new object, kind of like you might do with creating a new window in normal Windows programming). Also like Windows I have lists of button objects and such contained within the menu 'windows', almost as if I was reimplementing all of the Windows GUI from scratch. The reason I say it's like a tree is that you can basically get to *anything* game-data-related from the single 'game' pointer. Ideally you don't want to have to tunnel down like that, it's bad like global variables, but what it means is that when you come to write something later and realise you don't have a good interface for it, and you only want to do it in one little case anyway, you can always bodge out the data you want. Also it means you can pass groups of data to functions, eg. my current project has a 'room' object within 'game', and a list of 'things' within 'room', where 'things' are either players, exits or objects. It makes it easier to write functions that act on stuff within the room, such as a collision detection functions - you can pass the room pointer, rather than the list. And then when you later realise you also want a room map that isn't made up of 'things', like a heightmap or whatever, your collision detection function doesn't have to have its prototype changed to take more parameters. As I said in the first place, this isn't perfect and tends to make the code a little tanglier than necessary, but it's the balance between the sins of "messy" or "too neat to be usable" that works for me. Edit: another advantage of this structure is that it makes it relatively easy to back-access stuff from plugin DLLs and the like. roomforthetuna fucked around with this message at 01:24 on Aug 26, 2010 |
|
#
¿
Aug 26, 2010 01:18
|
|
|
Internet Janitor posted:If the lantern is basically just a constant circle of illumination centered on the player, couldn't you precalculate a "mask", representing the light added to tiles?
|
|
#
¿
Aug 28, 2010 16:06
|
|
|
Internet Janitor posted:roomforthetuna: Sure, or just do a simple tween from whatever the background illumination level is to the sum of the mask and the background. Just a single tile-based lighting mask wouldn't be enough to cope with those 32x32 possible lighting states per tile. But you could do it as a small lookup table of lighting masks. (All of which is still moot because what he wanted was simple enough that it almost certainly wouldn't be worth precalculating anyway, even if your processor is from 1982.)
|
|
#
¿
Aug 28, 2010 20:14
|
|
|
Internet Janitor posted:Take another look at my code- So I was saying that in order to duplicate the effect he currently has, but using precalculated values, he'd need a lookup table of precalculated masks that chooses an appropriate mask based on the light's position within the tile it's on. (None of this is true if his movement method resembles Nethack, with no steps smaller than a tile.)
|
|
#
¿
Aug 28, 2010 23:04
|
|
|
Bob Morales posted:What's a better way to lock my game to a certain frequency other than SDL_Delay()?
|
|
#
¿
Sep 17, 2010 20:31
|
|
|
Problem I see there - if you pressed "left, left, left, left" within one frame, only one of them would do anything. Or if you pressed "left, left, left, right" you'd come out of the PollEvent loop with just "direction==BZ_MOVE_RIGHT" and all the lefts would be lost. And if you pressed "left" and then unpressed "left" in one frame, you come out with "direction==BZ_MOVE_NONE". Your treatment of pressing up appears to be alright though.
|
|
#
¿
Sep 17, 2010 21:54
|
|
|
Bob Morales posted:I haven't looked at it in a while, I'm not sure why I split it up to handle 'up' differently.
|
|
#
¿
Sep 17, 2010 22:25
|
|
|
Your Computer posted:Another thing I wonder about is distortion. I made a tall box and positioned it down the y-axis but it didn't get distorted no matter where I positioned it
|
|
#
¿
Oct 2, 2010 16:00
|
|
Since I'm going for the GTA 1-look I want the perspective to be distorted towards the viewer so you can view down the sides of the buildings. Am I positioning the box wrong or is it not tall enough?
|
I have a question that should be pretty simple - what's the best (or a good) way to make a color-configurable object in 3D, such that you can have ten of the same object with different colors and without ten duplicates of the model and without changing the vertex data between renders? For example, say I wanted to use a flag object with a fixed pattern but three user-configurable colors. I figure one way would be to split the object into three sub-objects and render them each with different colored lighting. Is there a better way than that?
|
|
#
¿
Oct 26, 2010 18:55
|
|
|
OneEightHundred posted:Most games that do this have separate texture overlays for colorable parts.
|
|
#
¿
Oct 27, 2010 17:55
|
|
|
Still not sure I'm getting how this works - what if you have ten guys with indepenently colored shirts, pants and hats? Would this involve rendering with basetexture and three other textures for each object? And if so, is that really going to be quicker/better than rendering it as three or four objects with only one texture each? Also not getting how you'd do shirtmasktexture*shirtcolor - is shirtcolor being set as a variable in a shader or something? (So far I'm still using the old FVF so I'm not really sure what you can do with shaders.)
|
|
#
¿
Oct 27, 2010 21:29
|
|
|
OneEightHundred posted:Coloration masks are single-channel so you can stuff up to 4 of them in the same texture. quote:Also FVF is obsolete as of D3D9, having been replaced by vertex declarations, which are better in every conceivable way. Sorry if that sounds ungrateful, I do appreciate the advice and am certainly filing it away as a thing you can do with shaders that I didn't know about (especially sneakily slapping four 'grayscale' masks into one texture).
|
|
#
¿
Oct 28, 2010 02:47
|
|
|
OneEightHundred posted:If your target minimum is DX9, you should be using vertex declarations, not FVF. Eh, just checked my girlfriend's new-low-end laptop and it supports DX9 and puxel shader 3, so I guess it probably would be okay to stretch my low-end support up that far. That said, I'm very unlikely to need or want any of the really clever stuff for my project - it's pretty much comprised of 2D stuff (some of which is made of basic 3D to produce a "Flashback" sort of look). As such I barely even need texture mapping (except as used for sprites), and certainly bump mapping would be ridiculous in this context. Edit: But I should probably learn shaders anyway because my backburnered project will certainly want some of that prettier-looking stuff. roomforthetuna fucked around with this message at 18:52 on Oct 28, 2010 |
|
#
¿
Oct 28, 2010 18:44
|
|
|
haveblue posted:Put it this way- anything you are currently calling glTexEnv or glActiveTexture to accomplish (I forget what the DX fixed-function equivalent to these are) can be done much more cleanly and easily with a shader.
|
|
#
¿
Oct 28, 2010 21:54
|
|
|
I would say (as others have implied but not made entirely clear) that if you're doing your game data in XML or JSON, you might as well do your save files in the same structure. It seems silly to me to implement serialisation for a thing when you're already using a data structuring library of some sort, and you'll have a much easier time debugging a human-readable save file! (Unless you strongly object to people cheating by save-file editing too easily.)
|
|
#
¿
Oct 29, 2010 21:35
|
|
|
hayden. posted:From what I've read online there's really no way to prevent decompiling pretty much anything. If this is the case, though, then why don't we ever see people decompiling games and modding them? Are these large scale multi-million dollar programs just too complex for a few people to do this on their own?
|
|
#
¿
Nov 12, 2010 05:27
|
|
|
Orzo posted:Although I prefer composition over inheritance, it's also a design smell when you have an interface where implementors have half of the methods unsupported. For example, let's say IEntity has an UpdatePhysics method, a GetRenderInfo method, and a CheckCollision method. If you have an entity with no collision (say, a particle effect), you're now performing a noop on CheckCollision. Or if you have an invisible wall, now you're talking about returning a NullRenderInfo, or something similar, on GetRenderInfo.
|
|
#
¿
Nov 12, 2010 18:36
|
|
|
Zerf posted:I think his concerns are legitimate, you don't want to execute function calls if they just nop. You have multiple options to this problem though, set a state flag on which updates to run for each entity or keep objects which needs physics objects in one list and renderable objects in another(and if both are needed, in both lists). One list for each state permutation seems like worst solution you can come up with, but I think we all agree that it's not an option.
|
|
#
¿
Nov 12, 2010 19:13
|
|
|
To me it looks like (unless you have tens of thousands of objects active at one time) the very small efficiency loss of calling a virtual function that just returns immediately for objects that don't render or don't do physics is well worth it for the sake of simplicity versus the tangle you end up with if you have three or more distinct sorts of objects all cross-referencing each other. With the "single object, null interfaces for things it doesn't do" model you don't have to worry about reference counting on the transformation objects (or however else you were planning on dealing with cleaning up an object that's referenced from two or more places at the appropriate time), and it's not like the null function overhead is pure cost - it's partially offset against the management costs of dealing with the multi-referenced stuff, that you don't do. But mostly it's the simplicity that seems like the big benefit. vvvv I can't think of any way you could manage a tangle of mixed types cross-referencing each other more cleanly and simply than you could manage a single set of objects with the same available functionality some of which is just blanked for objects that don't care about it. Though I could see maybe an argument for the objects having some sort of more C-like behaviour, wherein some of the functionality might be set per-object rather than per-class so that you can have any combination of physics A or B and rendering X or Y without having to do any multiple inheritance malarkey. roomforthetuna fucked around with this message at 00:22 on Nov 14, 2010 |
|
#
¿
Nov 13, 2010 22:47
|
|
|
Vinterstum posted:The point is that unless you have experience with a couple of game projects already (your own, or in a team, whatever), thinking up base engine designs is about as useful as working out a football strategy without ever having watched an actual football game. It's starting out in completely the wrong end of things, and you'll probably end up with something which just isn't going to be a good fit for an actual project and will need to be redone anyway.
|
|
#
¿
Nov 14, 2010 01:36
|
|
|
OneEightHundred posted:There isn't a whole lot of discussion on it because it really hasn't changed all that much since the late 90's, aside from the proliferation of lag compensation which basically always follows either "trust the client" or "try performing the action based on where things were at a previous point in time." And there's the unusual method I'm using for the non-MMORPG parts of my game, where it's a mesh of peers with a synchronised timer rather than a server (so there's less lag, and MMORPG-style instant response for your own actions), though that's really a subset of "try performing the action based on where things were at a [not necesarily previous] point in time". Still, it's a different consideration. There's also considerations of whether you have one giant scalable server or some sort of much simpler lobby that spawns mini-servers, which again depends on your goals. Unfortunately I can't recommend any books or articles, because I pretty much hodgepodged it together from random gamasutra articles and manpages. At a lower level, you also need to consider what you're using - DirectPlay, some library like libevent, raw C sockets? If you don't send everything through a server how are you planning to deal with masqueraded networks?
|
|
#
¿
Nov 21, 2010 16:14
|
|
|
Sagacity posted:I don't want to exclude any devices that don't support Flash.
|
|
#
¿
Dec 13, 2010 16:14
|
|
|
Sagacity posted:Well, yes, but that's a target audience I don't want to ignore (Hasn't someone made a Flash compiler that makes an iPhone app out of a Flash thing? Won't be in a webpage but will be supporting iPhone, if you can do it that way.)
|
|
#
¿
Dec 13, 2010 17:48
|
|
|
Senso posted:Well, Flash works on Linux. As does HTML5. As do most Java games. There, you've got 95% of browser games covered running on Linux.
|
|
#
¿
Dec 13, 2010 23:41
|
|
|
Orzo posted:I suppose the easiest technique here is to write a function that, given the position of the 'Top Left' and 'Bottom Right' vertices as anchors, and a rotational value, calculates the final Position (x,y) and Scale (sx, sy) of the new shape. I'm going to see what I can come up with, but my math is a little rusty here, does anyone know a way to do this easily? Or perhaps a better technique than what I'm suggesting? As for the final position, that depends how your objects are anchored - center, a hotspot, the bottom left (untransformed) corner? Regardless it should be pretty easy to get the new coordinates given that you have your worked-on corner's coordinates, a scale and a rotation. It sounds like you might still need to decide on how a rectangle is anchored, which would be your first priority.
|
|
#
¿
Jan 12, 2011 19:46
|
|
|
Orzo posted:The anchor is always the center of the rectangle. Thanks for the input, seems like the solution to every problem is 'convert it to local coordinates' and work from there. Any other suggestions are welcome, I suppose I'll mess around with this on paper.
|
|
#
¿
Jan 12, 2011 19:58
|
|
|
If that's how you choose to do it, sure. Doesn't seem like a great idea to have objects anchored by their center in every context except scaling, though. My way, if your rectangle was (0,0) - (4,4) with no rotation, if you drag (4,4) to (8,8) then the new rectangle would be (-4,-4) - (8,8) The downside of my way is you can't scale by a single pixel, the upside is you get a consistent interface where rotations, scalings and positionings are all based on the center. (And it's marginally less effort to code because it's consistent.)
|
|
#
¿
Jan 12, 2011 20:24
|
|
|
By "except scaling" I mean when you rotate the thing in the editor it's going to be rotating around the center point. When you move it, you're going to be moving it by the center point. When you scale it is the only time you're going to be interacting with it as if it's not anchored on its center point. But if you don't think your users will like it scaled from the center then don't scale it from the center, that's fine. I don't know what sort of entities you're considering - for me, I would rather game-monsters and other such moving objects scale from the center, but if I was making floors and things I'd probably want them to scale from the ... hell, I don't know, nothing really makes consistent sense for floors, because you'd want them to anchor from the other 'surface' side, while moving the surface, but that would give you no interface for thickening a piece of floor. So I wouldn't care between center or opposite-corner scaling, they'd both be equally frustrating.
|
|
#
¿
Jan 12, 2011 23:12
|
|
|
Orzo posted:You make a good point, but indeed this is primarily for floors, walls, etc. I want to easily be able to drag vertices and have them snap to the grid, but I don't want to change a perfectly good data model. code:
|
|
#
¿
Jan 13, 2011 03:12
|
|
|
Fair enough, good to see you've considered it, and you're right that (for steep slopes at least) dedicated shaping sprites will look a lot nicer.
|
|
#
¿
Jan 13, 2011 03:48
|
|
|
HappyHippo posted:Another solution would be to have every unit remember what team it's on, but that lets bugs creep in because it's possible for the program to be in a state where the unit thinks it's part of team A while team A doesn't think it owns the unit. If I'm careful this won't happen, but the possibility is there, especially with the unit - tile relationship and the units moving around and dieing. It does give you more opportunity for bugs if every time something updates it has to be updated in five different places, but you should be boiling that update action down into one function anyway. Also, it seems weird to me to have teams bother to remember what units are on them - when do you need to do an action on an entire team? Is it really critical that such a lookup not be a mere 6 times slower [do you have 6 teams?] It makes a lot more sense to me to have the unit store what team it's on, because that's the way round you'd be needing to check most often. (eg. when you click a unit, you'd first find the unit hopefully from some sort of location-based lookup, then you'd need to know what team it's on.) The only reason I can think of to have the team store a list too is if there's a big performance saving during rendering by rendering all the guys with color scheme A first then all the guys with color scheme B, saving on changing a setting back and forth - and I really don't think the performance loss of just going through the whole list of units 6 (?) times, once for each color, would be that bad. (Unless you have thousands of units per team.)
|
|
#
¿
Jan 18, 2011 21:57
|
|
|
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
|
|
|
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
|
|
|
I'm not sure I understand your complaint - Unity is too easy? Is there something about your game idea that you feel Unity can't do? If there's no part it can't do, and the performance will be fine (which obviously it will for a turn-based game), and you find it easy, then surely the engine you should use is Unity? I was eyeing Unity for my next project, but since I want to use a custom input device I suspect I'd need the expensive super-pro version that supports custom plugins, which is an unfortunate limitation that counts against it for me, but I don't see anything like that in your idea.
|
|
#
¿
Feb 15, 2011 19:47
|
|
|
|
| # ¿ Apr 28, 2024 01:02 |
|
|
Ah, I haven't actually tried Unity myself, so yeah, I agree that a drag-and-drop level of easiness would be pretty disturbing even if the output is perfectly fine. I'd also be a little afraid of 50MB of download required for a plain Tetris clone that should be measured in kilobytes, based on that. Since you've played with it, would that fear be justified? Are your tutorial binaries large / large DLLs required?
|
|
#
¿
Feb 15, 2011 22:07
|
|