jake13jake

I'm having a hard time figuring out what all the 10,000s are for. Generally I'd use something similar as a cop-out of a rounding situation (where there is generally a far more elegant solution). However, if it has some particular meaning, I'd set it as a constant. I'm taking that s is the ship, and rot is the ship's rotation, though it would be more clear if the variable names were more verbose. No idea what pi is. No idea what the bitwise-and is for, though I know if it weren't there you could get rid of the 10* and /10. I'm !@#$%^&*uming that millDif is in units of milliseconds. Since maxDistSq and distSq are only used once, I'd just calculate them in the conditional statement, Either that or give them verbose names, because then it would have the reason of being there for people to understand the code. Unless this is integer division, I have honestly no clue why there's division in this statement: (s->loc.x / 10000 != newx / 10000) s->vel.x = xvel; s->vel.y = yvel; s->display = true; s->rot = sm->frameToRot(frame, s); // look at the timestamp and compute the predicted "correct" position for the player int millDif = 10 * (((net->getServerMilliseconds()/10) & 0x0FFFF) - pi->getValue("timestamp")); // millDif is positive, how much later it is than when the event occured // predicted correct positions int newx = xpos * 10000 + (xvel * millDif); int newy = ypos * 10000 + (yvel * millDif); // these are how much we are "off" by int dx = (newx - s->loc.x)/10000; int dy = (newy - s->loc.y)/10000; // resetDist is in pixels u32 maxDistSq = resetDist * resetDist; u32 distSq = dx * dx + dy * dy; // if we're drawing too far away from the predicted position, jump the player to the correct spot if (distSq > maxDistSq) { s->loc.x = xpos * 10000; s->loc.y = ypos * 10000; } else { // otherwise cheat with the velocities to fix the player position smoothly // s->vel = pixels/10sec, velAdTime = ms, newx/s->loc.x = 10000*pixels if (s->loc.x / 10000 != newx / 10000) s->vel.x += ((newx - s->loc.x)) / (velAdjustTime); if (s->loc.y / 10000 != newy / 10000) s->vel.y += ((newy - s->loc.y)) / (velAdjustTime); }

That would actually be something that could be added. Anyways, I've been trying to write this level-editor with pygtk, and will probably rewrite different parts of it to death, but I've decided on general capabilities that I want to have done for May. This includes defining tiles in terms of vertices, edges, and two-dimensional patterns, each with different properties, as well as multiple layers of arbitrary sizes, a defined background color, and the ability to scroll background layers at an arbitrary rate against some other layer. The layers don't necessarily need to be interacted with but I do want to make that possible. I can just imagine a wormhole that instead of warping you to some random location, warps you to some area below everyone else. With layers that are different sizes from the main (perspective) layer, they will scroll relative to the main layer (smaller layers scroll more slowly, larger more quickly). There's also the constraint that the size of the smallest layer is the largest the screen can show. Scrolling layers can be of arbitrary size, but are repeated and scroll at a specified rate relative to the main layer. I don't think this is necessarily the most original idea, but I want to add it and see more functionality than I've typically seen games with scrolling backgrounds present. I'll tell you something though, the two biggest issues I have right now is that this is the first large project I've done using either Python or GTK+, so I'm not experienced to know what the best ways to structure everything surrounding everything is, and particularly efficient means of drawing multiple layers. The fact that I'm actively learning while programming this means that I have to restructure my code after every milestone. I was wondering if anyone who knows the gdk portion of the gtk+ library would be able to help me out a little bit.

Basically, you want to know about the file format? Which language do you plan to use? DCME (and CLT) does have a walltile feature, that allows you to tile bases quickly. However, the feature is quite limited... Also, what would be nice is if the program handled itself the rotation of the tile graphics and such... I was looking forward to redo the whole walltile feature in DCME. There is also a feature to generate a walltile set, but again, it is very limited and only does a bunch of rotation and flips. If you can come up with algorythms that do all that nicely, would be great... I might be tempted to port them in DCME as well . DCME is in VB6 by the way. Rotation, in itself, would have to be implemented in the game engine to be of any practical use in a tile editor, or you would have something that builds rotations into the images during the level compression.

Yea, that would be an example of the capabilities. The main difference is that the autotile tool there has an absolute definition of tiles used and in what patterns, acting as a predefined macro of sorts, which is obviously going to be a bit more efficient than mine, but it is not nearly as flexible. With what I'm doing, you can build any set of constraints among any set of tiles in any order.

Well, not so much any of the above. I've used SSME and CLT, never actually heard of DCME until you just mentioned it, but I suppose I'll have to check it out. I'm not going to be working on a compression algorithm or an autonomous generator, though one could presumably do that. Essentially, what I'm aiming to do is make it much easier to tile on a larger scale. Subspace is a good game to test this on, but the concept isn't going to have most of it's value in games like Subspace. There are games where these concepts would save time on a scale that makes applying this to Subspace specifically seem extraordinarily trivial. I'm not saying it wouldn't surp!@#$%^&* available tile editors for Subspace, it just wouldn't do it by nearly as much as with other games. Anyway, even using this kind of tile editor will require defining tiling patterns for an arbitrary tileset. Ex: -'s are horizontal wall tiles (which can be a horizontal repe!@#$%^&*ion of any nxn set of tiles) |'s are their ends. |------| You would select the pattern, it would implicitly place the end tiles, you could extend it in either direction for as far as you want, or you could extend a vertical pattern from anywhere in the horizontal pattern. I call these one-dimensional patterns because they are meant to work in one direction, connecting to stubs (like the pipes), voids (where it just doesn't matter if the pattern disappears), or other one-dimensional patterns (ex. a horizontal wall). Now, this one-dimensional repe!@#$%^&*ion of tiles could actually go in directions other than 90 degrees, but the idea is that this particular type of pattern is meant to be repeated in one direction. One-dimensional repe!@#$%^&*ion often occurs among tilesets that show two-dimensional patterns. Gr!@#$%^&* in an RPG for instance, can be extended in any direction. However, if you have a spot where the gr!@#$%^&* ends and there's water or a desert or anything, there are going to be tiles specifically meant for dividing them, and these are almost always of one-dimensional repe!@#$%^&*ion. If there's an online game that accepts player levels at a high rate, it could run a server that loads the constraints of the tiling patterns to the level editor. This could save a lot of work in checking for tile errors, for the simple fact that the tiling patterns should outright prevent them. I actually wanted to make a game engine for my independent study, but my professor asked that I focus on something a bit more specific, and something that I'd learn a bit more from. I figured from my own experiences, the amount of time spent on building levels for games by far surp!@#$%^&*es any scripting or programming that I've ever done for games. Not so much because it was my focus, but because it was the most tedious, most horrible work. However, creating or contributing to a game environment shouldn't be tedious, it should be, far and away, the most rewarding work anyone could do. Because of this, I want to reduce the amount of work it takes to build levels. I'm going to take a wild guess that with the scale of this project and my grade depending on the final outcome, this is going to keep me extremely busy for the next three months. Fortunately I'm doing this because I ran out of requiement space on CS classes to take. Doing this in place of taking Visual Basic, where I wouldn't learn a !@#$%^&* thing.

I'm going to be making an advanced level editor for an independent study. Essentially, I'm seeking to add extra dimensions to the artform that allow for the creators of tilesets to define and modify structural constraints in the use of the tiles, which will in turn accomplish two things: help maintain the artistic integrity of the tileset, and allow for higher quality rapid development of levels. i.e., one could say that I'm building a tile editor on steroids. I don't intend this to be limited to Subspace, but my observations of patterns involving the use of tilesets have me looking at Subspace as a strong place to start. I have noticed two kinds of patterns in the use of tiles in almost all games: one-dimensional patterns, where a certain arrangement of tiles may be repeated sequentially, as though in a line. two-dimensional patterns, where a certain arrangement of tiles may be repeated in multiple directions. Subspace is quite heavy in one-dimensional patterns, and two-dimensional patterns, in most cases, rely on one-dimensional patterns in border spaces between different two-dimensional patterns. This is not so much the case in Subspace, where two-dimensional patterns like safe-zones and goals typically don't rely on one-dimensional patterns at all (or, well, on most servers). I do intend on implementing both of these concepts strongly and allowing them to link together, but I believe I should probably be focusing on one-dimensional patterns before expanding into the area of linking them to two-dimensional patterns. In order to apply this to Subspace specifically, I will need access to file i/o functions for levels in Subspace. I would expect that this project has, at the very least, an importation function for rendering. I have tried compiling Discretion on Linux many times before, but have generally failed to do so and thereafter lost a bit of my drive to skim through the source code. In other words, I was wondering if anyone would be interested in contributing in this sense when I get to the point of where I need to be in terms of a GUI environment.

a correct compiler won't allow it It's 5 times a second at most... 90% of seconds it will never get executed. doing .c_str() doesn't take any more memory, so i'm not really converting it back to an array, just getting a pointer to the string's char array. That's sort of why a compiler should never allow changing values of a const char*, since if one could modify the array returned by .c_str(), the length/capacity/hash of the string would be incorrect. Extra memory is used and calculations are performed on the declaration of a string, not so much by using .c_str(). And yea, a compiler shouldn't allow that because the compiler should be able to see that the operation doesn't work. The const char * traced from one function call (it may not even be the first), up to a certain point that I haven't looked beyond yet, faces 4 conversions/extractions. It doesn't help the readability of the code. I would like to help improve this.

void clear(const char* array) { array[0] = '\'; } will not compile. (or shouldn't, anyway) It depends on the compiler, but in either case, it generally causes a runtime error for trying to write to read-only memory. Still, if a string copy is created, it will probably create a pointer for appending and iterators, a value for length, a value for capacity, a hash value for comparison with other strings, etc. A C string, on the other hand, is just a pointer to a sequence of characters terminated by null and doesn't require all of the additional info. I don't think it's such a big deal, but it would definitely be a lot cleaner to stick with C strings unless there would be a lot of different string operations, etc. If there's a reason to use the string that's not toLower, it should be calculated when it's initialized, not in the middle of a stack of function calls. Although, for animation settings, what's the purpose of case insensitivity? It's just cleaner and easier to read through in the long run if there's more consistency. In Java, you can't put primitive data types in maps, etc. (which irks me), but you can in C++. This advantage is huge and should be utilized. For instance, the map instance singleAnimationSettings is . The aforementioned string instance name that is converted to lower as a string and then passed again as a C String to getAnimationSettings. In getAnimationSettings, it is then again looked up in singleAnimationSettings. The character array is then implicitly converted to a string. In the end I'm not sure how many times it's been a string and how many times its been a character array, just that it's been converted back and forth enough for following the code to be somewhat antagonizing. @Cerium: I'm more concerned about the maintainability of the code.

A constant pointer... the question is, is it pointing to a constant value? I guess most versions of C++ will do that implicitly. Concerning the physics module, I've seen scarier. The only movement system I've ever written was 8 directions for a player with a rectangular area. There's actually no need to have anything else in movement in a square tiling system, because the tangent lines of any collision are the same as the lines of a rectangle. The syntax was moveObject(dx,dy,object), where the object had fields for x, y, width, and height. It returned boolean to whether or not the player hit a wall when moving. The tileset array was directly accessible via the scripting language. Each tile had a value, there was also a built-in function to get the type of the tile (not the value)... probably implemented with a hash table (useful). I also made it so that arbitrary types of tiles could be set to be detected as a wall, and some other guy later added in specific exception !@#$%^&*ignments (!@#$%^&* closed-source games where they only give you scripting interfaces). There was also an offset value for the x and y checking. I could have improved it for higher speeds by using divide and conquer, but it didn't really matter consider no one would ever be going that fast. The damage system, that I was forced to script serverside, not a lot of people were happy with the feel of it. The really hard to grasp parts of it were how I moved dx and dy independently (but effectively), and the functions I made to check for a wall in the dx/dy areas. Pretty much checked the area that the player was moving through for wall tiles, and rounded off the player's x or y values at the wall as a side effect. It's actually a lot more easy to be efficient if you don't have to check pixel specific areas for walls. Subspace, on the other hand, would need to change the x and y vectors as a side effect, and currently doesn't need to check for pixel specific areas. Edit: Actually, that was for any direction, just you only had up-down-left-right to press by default. I actually made a few scripts that manipulated the motion independently using the same functions.

const Animation* playLoopingAnimation(const char* name_cstr, int xPixel, int yPixel, bool centered, int layer) { string name = name_cstr; toLower(&name); FullAnimationData* animationData = getAnimationSettings(name.c_str()); return createNewAnimation(animationData->imageIndex, animationData->animationTime, animationData->animationTimeOffset, layer, xPixel, yPixel, true, centered, false); } Okay, I'm a bit unclear on the cleanliness of all the code I'm looking through, especially on a lower level. First, there's a string declared from a C string that's passed as an argument, the sole purpose of which is to convert the C string to lowercase. It's passed to the next function as a C string as well. Therefore, I'm not really getting the utility of converting it to a string at all. I mean, all the toLower function does is run the tolower function on each character of the string, which could be as easily done using a C string. Aside that a function call on each character creates an unnecessary amount of overhead (it could be done in the toLower function without a separate function call for each character). In addition, converting something to string without needing to frequently operate on that string using string class functions really creates even more of an unnecessary amount of overhead. A string will pre-calculate certains things to assist in certain operations. It will try to do so efficiently. However, if you don't need to use a lot of string class functionality and often for a specific case, it is probably better just to leave it as a C string. Sorry if I come off as anal to you, but at least now I actually feel confident I can contribute. I'd still need to get a feel for all the code. I also would need to be able to get it to compile, and preferably to be able to get an IDE that would be able to recognize where all the header files are (yea, I really do like Visual Studio, but I haven't found as good of a replacement for C++ apps in Linux). This kind of string handling also makes me a bit nervous about how other code might be handled. I'll probably spend a lot of time simplifying and trimming everything down once I feel at one with the code, but I'd also be concerned about communicating with everyone else working on this since I am liable to making drastic changes in order to garner efficiency.

I honestly don't care for VoIP at the moment. It could be great for team freqs in the future though, depending on how many people utilize it. However, right now, I just want Discretion to compile on Linux. Otherwise I'll have a hard time figuring out how it's supposed to work and contributing. I'll try to see what's up with it tonight while I have some free time, though.

Lol i have a gamecube, ps2, gameboy, gameboy advance, gameboy advance sp, and a DS light but i had to buy them all my self Oh, what I meant is: portable platforms don't count! I actually have a broken gameboy advance sp, and it really pains me that DS broke the backwards compatibility with all gameboy games.

I only have a gamecube, and I hardly use that.

The linux version doesn't compile.

Playstation is based on Linux and OpenGL with some proprietary extensions, but I wouldn't say such a thing would be a big deal. If a basic client gets done and we can market it around the open source community, hobbyists will probably modify it to work on PS3, etc themselves. Since Microsoft has an extremely small market share of the open source development community, I really doubt such an idea would proliferate without posix support.

next one: make: *** No rule to make target `../Modules/Graphics/SDL Graphics/SDL_image.h', needed by `DiscretionLinux/Modules/SDL Graphics.so'. Stop. I really know nothing about how makefiles work, !@#$%^&*. What I really want to do is work on this project. But !@#$%^&*, I'm using Linux.

I actually believe voip is patented... oh wait... nevermind... it's just for voip conversion to analog signals.

It would be useful to be able to do any angle, and simpler. The fact is, all that's being done is a reflection of the motion respective to the wall. The problem with that, though, is that graphical tiles are being used rather than object shapes with textures, and also that the basis for wall detection in most 2D games like this seem to be based on rectangular areas (which can simplify things a bit, but is nevertheless less powerful). Can't say I've actually looked at what bak has done yet, but I just downloaded through svn. p.s. is there any sorted to-do? and also, trying to compile DiscretionLinux gives me error 1. ../Modules/ModuleManager/../Module.h:13:29: error: Shared/Snprintf.h: No such file or directory make: *** [DiscretionLinux/Modules/ModuleManager.so] Error 1

Okay, so Continuum doesn't work on Vista? Or why was there a strike-through on that first post? I didn't read the entire thread. Anyway, yea, Continuum does need a cross-platform client. I'd be willing to help, but I'd definitely have to do a lot of learning, since I have no experience in network coding or OpenGL (though I know people that do). Second, didn't someone make a linux testing client that was under the FreeBSD license? Can that be relicensed under the GPL? It would probably be a good idea to pick up that project instead of starting from scratch. Essentially, getting the clone done before anything else would be wise. Looking on sourceforge: http://sourceforge.net/search/?type_of_sea...;words=subspace Anyone recognize any of these?