|
Socoder -> Blitz -> some help with a space shooter |
|
| Sun, 26 Dec 2010, 04:56 | |
|
Teasy |
btw , thx for linking to the tyrian gfx! that's really awesome to see  most of the image dimension problems i have come across deal specifically with memory handling, so any DrawImage/TileImage calls will not cause any problems. Only the Load(Anim)Image and CreateImage calls can produce 'wild' system-wide effects ^^ Although CreateImage, when using a single frame, has proven to be way more stable in the past. well, the thing is, looking at my situation, on some days my computer is more sensitive than on others, so sometimes a "severe" problem can have zero (!) impact. also, i often run with setups that are 'unusual', for example 1 computer having 2 monitors, with the monitor on the right being the 'primary', effectively making the desktop start at (-1024,0) *lol* ( this confuses the heck out of some programs ). after a few more swaps of monitors etc, and some cleaning up of my workspace, i've done some more extreme and extensive testing on the (anim)image boundary limitations. (un)fortunately (^^) i have not been able to reproduce any negative effects that i have previously mentioned  ( relating to the image boundaries only ) i have tested the following things with success: - creating/loading (anim)images of 10,000 pixels wide - managing/handling (anim)images of 10,000 pixels wide - drawing, copying, etc so perhaps keeping a limit of 2048 pixels (on file) would require no/little modification of existing code/media while still being fairly compatible; e.g. only crashing on 'some' pcs ^^ ( or on 'some' days ). adding to that, a ScreenX * 2 size run-time generated image should cause little to no problems. ahh, well, i guess your excellent docking type can be implemented in a jiffy ^^ some pseudo-code for fun: btw, i see a nice optimization potential for your ShipTakeProxyDamage: Simply wrap the VectorDistance check in RectsOverlap first for an immense CPU speed increase: Where bx,by,bw,bh is the 'bomb rect' and sx,sy,sw,sh is the 'ship rect'. Perhaps in your new ObjectCollide function, which checks for a radial collision, a similar RectsOverlap check can be done first to avoid a (slow) square root calculation often. i guess the use of a (simple) scenario 'system' in the style of x-wing/tie-fighter would continuously create a tension build-up. some days ago i got a tune in my head while playing with your game  so i 'transferred' it to the computer, and uploaded it here: wayout 1a part 1 (with player) (2010-12-26) (zip) i don't know if the style is what you're looking for in your game, but i thought i'd share it anyway, because i like it very much btw, i see that your 2nd [ code ] tag in your previous forum post is missing a forward slash much love & enjoy, my friend 
|
| Sun, 02 Jan 2011, 15:26 | |
|
j\\'ordos |
Another week has gone by and another year started! So, the background won't be a problem then, that's good Would there be a way to procedurally generate the stars in the background instead of storing them in an image somehow though? I implemented the radius based collisions but I didn't notice any speed gains Still using imagescollide for capital ships though, might replace that with the vector library, it seems easy enough to use&implement For the docking, I also want the docked ships to actually become one with the carrier so to speak, so once they're close enough and the speed is low they get magically transported to the center of the carrier and receive it's same orientation and speed, until the player starts thrusting again (or in case of an AI ship when the ship is reloaded) Thx for the optimization! By the way, I dug up an old PIII laptop and decided to test the game on there. I didn't expect it to run well but it was pretty much unplayable Ah about the music, I myself wasn't really sure on what to do, I was thinking I'd try either classical music (copyright issues) or modules (smaller, set up for looping most of the time) and see how it'd work out I also considered using tyrian midis, but blitz support for midi music is pretty awful. So if you like to make some music for it, please do! I like the tune and think it would fit well for the shop between missions? (it's a bit happy and joyful for a combat theme  )Anyway thanks again for the input and a happy new year to all! |
| Wed, 05 Jan 2011, 15:47 | |
|
Teasy |
Yes, in fact, I generate stars at run-time in my game Terra Colony (Code\StarField.BB). The above algorithm also fairly evenly spreads out the stars across the screen. As for obscure ImagesCollide problems, I have discovered something new (yet another big break-through for me ^^). When using the commands Locate, Print and Write, the chance of a Memory Access Violation increases tremendously. I've also found that the use of FreeFont also causes strange behavior, related to ImagesCollide. Perhaps just getting rid of the Write/Print commands in your game will alleviate many ImagesCollide problems. Combining this with a (perhaps design-time, run-time or even real-time) conversion of 2-power image sizes and reasonable image width constraint would give a Very solid game For resolving 2-power incompatibilities, I remember having previously outlined and pasted code for: Converting (non 2-power [animated] images) to (2-power [animated] images): - outside the game, using an image converter utility. - during image loading (LoadImage), effectively increasing the image 'padding space' ('canvas'). - during image collision detection (ImagesCollide), (optionally) keeping a separate 2-power image frame/field for cached collision detection. I've noticed that the most slowdown on old computers are caused by large images. I think that if you simply remark the backgrounds, it'll double the FPS on old PCs ^^ This is also the reason why I went from using multiple screensize images to a single screensize image to paint the stars on (like in the StarField_Generate function above). Though I'm quite sure that you can safely put the 'minimum system requirements' in the 600 MHz range ^^ (If that has any importance or significance anyway )The videocard on old PCs is, I have found, the most significant factor. For example a GeForce 256 (first generation) with 32MB will run this game very well, while a card like an 8MB Riva128 (TNT2) would prefer some more optimizations Your new docking style/technique sounds and feels very cool and intuitive Perhaps the music I created (which is a module too btw) was more attuned to your vibration or the vibration of our collaboration than to the vibration of your creation
|
| Wed, 05 Jan 2011, 15:57 | |
|
Teasy |
Btw, there are also Tyrian music MP3s somewhere (and on my HD ^^)
|
| Tue, 11 Jan 2011, 09:21 | |
|
j\\'ordos |
I've got a quick question: is it possible to assign a default value for passing a pointer to a function? Like so: When I try this in blitz it gives me an error ("expression must be a constant") Sounds like I won't have to worry about incompatibilities too much for now then there won't be any print/writes in the game, I got a bitmap font from subspace ready I'll keep the radius collisions for fighters and capital ships will get a power of two imagesize. (outside of the game)Ah another point in favor of doing away with the tileimageing! I'll try to rip the code from terra colony Why are you creating an image though? reasonable image width constraint Well it IS quite tempting to put in a huge capital ship several screens wide at some point in the game, but since I don't have any gfx for that it probably won't happen anyway  And that pentium III has an 8mb Savage S3 card Heh I know of the mp3 versions but I refuse to use large files when there are tiny midis available that sound just as good I found a DLL file for midi plaayback in blitz, haven't tried it yet, but I think for this game midi would be out of place... Tracker music is the way to go!
|
| Wed, 12 Jan 2011, 15:28 | |
|
Teasy |
Yes, in Blitz (2D/3D/+) Null is actually not a constant ^^ Probably having to do something with its internal handling of the type lists, which was made controllable in BlitzMax. In this case I usually just pass Null as a parameter. Or you could use Object/Handle, which adds 2 typecasts. I've also found out that Blitz+'s ImagesCollide is much more reliable/stable than in Blitz3D, probably due to a completely different (video) memory handling system, which seems to cause the main problem in Blitz3D. I've even found some strange ImagesCollide behavior which relates to (some of) the programs running in the background (!). Playing music, watching movies, browsing etc, all seem to affect its behavior, which clearly relates to (video) memory allocation. I've even been able to devise a fool-proof reproduceable Blitz3D ImagesCollide crashing program ^^ which I now use to 'compatibility crash' (instead of test) a game/program at first run ^^ I think Terra Colony uses an 'over-layering' system with partial and/or customizable transparency and/or masking (or was that Futurity? hmm), in combination with a fading and screen transition system, for which a separate image could be used to apply the transition to. I guess another benefit for having a separate image is being able to update the image less often than every frame, but I guess for your game (and most of my other games) a simple "StarBlit()" would suffice ^^ One of my fantasies is also a (2D) game (with a pixely-low resolution) containing multi-screen ships (and planets) Perhaps using 2D-in-3D (in Blitz3D) is a better approach for this ^^ Ahh, with an 8MB card, the best (or only) way to make your game faster, is by decreasing the active video memory usage ^^ A great sound/music library I also recommend (also for Blitz) is called 'Bass': www.blitzbasic.com/toolbox/toolbox.php?tool=207 I think it plays most things that can be played, in most ways that one would 'normally' want ^^ Well, I hate giving you bad news (^^), but.. ..and even though Blitz (2D/3D/+), for me, has been and still is the most reliable and versatile solution for creating most software in very, very, very little time.. I've just tried playing one of my latest (and oldest) .IT files, which seem to 'crash with flying colors' on Blitz3D (!). My hunch is an FMOD bug that derives to panning (envelopes). On Blitz+ however, it works! (oO) And an old S3M/MOD works well on Blitz3D. ..You probably know about ModArchive Btw, my soundcard's "midi" volume is always turned way down ^^ I prefer using the soundcard's primary wave channel(s) so that I can choose to concatenate audio signal processing (like compressing/limiting) ^^ Here's a remix I did of Romeo Knight's Cream of the Earth in late 80s style with many 'well-known' samples: Romeo Knight & Teasy - Cream of the Earth (IT: 251KB) Note: My Blitz3D crashes with it ^^ I've reduced the size a bit, but I think that under 128KB (that's smaller than the original!) is possible too
|
| Mon, 14 Feb 2011, 07:17 | |
|
j\\'ordos |
Well not much has changed, but since it's been too long already here's a new version anyway users.telenet.be/V776822/Project/spacewars4_3.zip it has a better formation Ai and the foundations for a chatlog Also the radius based collisions for fighters are in and the capital ship image sizes are now a power of two.There is still a bug in there: sometimes the game doesn't get a proper new ship for the player when he's been killed and the game crashes. It has something to do with jumping to another ship manually using the +/- numpad keys before being killed. Haven't been able to reproduce it reliably yet! Another bug I remembered is that bullets & bombs are drawn twice for some reason (when the game freezes you can see there is a bullet or bomb 'trailing' the original. I'm quite sure only one bomb/bullet is being generated in each case. This bug has been there from the very beginning! Not sure where to look... Well I hope I won't have to port my game to blitz+ to get it running stable! Haven't tried running it on my old PC again, the background is still using tileimage for now.I actually used BASS before in FreeBASIC, it was pretty easy to use! Since your IT file (nice tune btw, it'll fit well!) crashes blitz3d for me as well I'll probably use that instead Anyway, enjoy the new version and let me know how well it runs! |
| Thu, 24 Feb 2011, 16:59 | |
|
Teasy |
thank you for the update it's nice to see a game grow so organically, with cool new enhancements and deeper improvements to enjoy. i hope you will enjoy creating the continuation of your creation as well * double draw looking at your code, and the gfx, cool new things etc, i can't find any double drawing going on. what i can find is that when you stop or break a game in debug mode, often it's in the middle of drawing operations, making various images and buffers overlap and intertwine in undesired ways causing for example a 'double draw' illusion/effect. you could try add a simple pause feature to see if double draw is real or not ^^ it may also help or change the buffer/drawing behavior if the game is run in fullscreen rather than windowed mode. * vmem i've added a little check to see how much video memory your game was using, simply adding below the Graphics call and adding above the main loop and it says ur game is using about 68Mb  i guess that explains primarily why on older computers it's slower. * imagescollide i seem to be getting a MAV on yet again, ImagesCollide, between ship and bomb it appears that there are quite some images that aren't 2-power, but ImagesCollide can even occur if all sane factors are catered for i recommend this ImagesCollide replacement in the meantime * peaceful at the moment i seem to be losing all interest in games that are primarily focussed on destroying other (virtual) players. though i was able to refrain from turning the bullets/bombs in your game into hearts, weapons into celestial hands, ships into rainbows and large warships into heavenly realms 
|
| Thu, 24 Feb 2011, 17:46 | |
|
j\\'ordos |
adding the pause function (just a waitmouse() when pressing P) I think it's quite obvious that only bullets & bombs (bombs not visible on screenshot though) are being drawn twice. I also remember the 'ghost' bullet being visible during gameplay way back when the ship speeds weren't limited yet and I could follow the bullets I had fired. The screenshot is windowed, but the same happened in fullscreen mode. Wow 68 Mb is quite a lot given that the gfx folder is only about 10 (most images are BMP too) Removing the tile background images reduced it by about 10 megs, so that would put the requirements at a 64Mb card. Can anything be done to reduce the size? For instance I think the subspace images are 8bit BMPs. I don't know what blitz uses internally, changing the depth in the graphics command didn't seem to affect the memory usage.Well if you're still getting crashes on imagescollide I may try the vector library instead! Not all images have been resized to a power of two, but the ones that are used in the imagescollide call are. (bullets, bombs & capital ships) Edit, oh wait, bullets aren't either And I'm afraid your latest suggestions won't make it into the game... Or maybe as a hidden mode on Valentine's day, like tyrian's christmas mode edit: looking at that screenshot it seems like Red 1 managed to hack into our freq's chat! edit2: come to think of it, maybe my computer is the cause of the double drawing problem, I've been having some strange graphical glitches with blitz3d since I got this new PC (with windows 7). Should check it on a different PC |
| Fri, 25 Feb 2011, 16:41 | |
|
Teasy |
* vmem iirc, in blitz3d it's 32bit for all images (by default). another option is to convert the 2-power images back to their trimmed versions, so that less memory is used. and then using either the ImagesCollide replacement or a custom collision system. after adding a little test, it looks like there are 2 other huge images: other loaded images < 5Mb (each, separate) mothership.png = 10Mb turretO.bmp = 25Mb other (runtime) images = 11Mb (total, combined) here are the stats from a simple image load modification: it shows the increment in video memory after each loaded image. and the code (if desired ^^): works in conjunction with startmem from previously illustrated example code. also, it doesn't seem to matter if png or bmp is used, at least on this pc * duplibullets i've added the same pause thingy u mentioned to the latest version of ur code, and i can clearly see them too! so i've added a small test to check if the bullets are spawned okay, by counting the number of bullets. and it appears the number of bullets is accurate. e.g. when i press fire, only 1 bullet is spawned, but i see 2 of them ^^ this info should simplify the hunt a bit perhaps an interesting sidenote is that if i lower the TargetFPS to something like 10 FPS ( i LOVE slow motion ) the distance between each bullet (visually) changes! e.g. on 10 FPS the distance is ~2 pixels, while on 60 FPS the distance is ~12 pixels. so the duplibug may be related to or located near the bullets' delta-time calculations. * the gift hm, lol, i love christmas and valentine ^^ ( hint: not because of the gifts )it is my intention to celebrate life every day 
|
| Fri, 25 Feb 2011, 19:06 | |
|
j\\'ordos |
Ah I compeletely forgot about the huge turret overlay image That one still needs to be replaced! Trimming sizes won't make that much difference, a meg or two at most. There wouldn't happen to be a way to control the image depth for loadimage commands in blitz would there? I actually found the problem with the duplicated bullets already! It was simply a missing Return call at the end of the update_particles and update_trails subs, which caused update_bullets and update_bombs respectively to be updated twice (similar to the problem I already had before with the player ship suddenly flying twice as fast when I added formations) This means they were also flying twice as fast and doing collision checks twice each frame!Thx again for the help edit: by the way, I have another basic math question! When I create a bullet it uses the sin/cos tables precalculated at 9 degrees intervals so the bullet will always travel the way the ship is pointing graphically. Now the yellow ships have a type of Gatling gun with a small amount of spread, so when the bullet is created it adds or subtracts a small amount of degrees from the ship's angle, but that should use the accurate tables since the spread should be less than 9 degrees. So what should the formula look like to achieve this? Currently it looks like this: Come to think of it, that +15 & -15 shouldn't be necessary anymore since the images are already midhandled (so sh\x & sh\y is at the centre of the ship's image already). wg\angle_start and wg\angle_difference is the angle added to the ship's angle. |
| Sat, 26 Feb 2011, 17:02 | |
|
Teasy |
* duplibug i'm glad u found the duplibugfix  and so fast ! * barrel hm, im not sure i understand how u want the barrels to work exactly. it sounds like ur barrels are all facing different directions? if i think about how barrels work normally, and in my game robotix, each barrel should be facing the same direction, so it's not the angle that requires changing. following that, i see that only the offset changes, e.g. shooting a bullet from each barrel at a different location, but in the same direction. converting this to pseudo code: x/y: bullet/bomb/missile heading will be same as the barrel's facing direction, so if the barrel is facing in the same dir as the ship for example: getting a VX/VY (or s/t in ur prog): (afaik this is a 'normal' gatling gun) but, maybe (  ) u want ur barrels to actually face different directions?'spread' as u say could be interpreted like that too i guess.. in that case, i don't know if u want the offset to change too.. but, to focus only on the angle.. (offset remains the same) here, spread is decided upon by your angle_start and angle_travel angles, which i do not understand as an example, let's take 3 barrels, with ur -18 (342), 0 and 18 degrees in an array called barrel_spread. then, having barrel_num to indicate which barrel is being fired. this, again, can then be inserted into the VX/VY thingy to find the velocities (or s/t in ur prog): (identical code as above) after looking it up, i see that the accurate tables are table_sinA and table_cosA. so something like this can be used: i do not know what u mean by angle_difference. i can't find it in ur program. perhaps u mean angle_travel, but that makes no sense to me * vmem there are some complicated ways, libraries and hacks, cheats and tricks, to reduce vram usage and/or to enable real 256-color mode. but! Actually, I think that BlitzPlus offers a way to supply a flag in LoadImage, which enables you to decide how to manage images in system/video memory. i've run a few tests to see how and when memory usage changes - both in blitz3d and blitzplus - with images having different colordepths (2,4,8,16,24 and 32-bit BMPs) - in different window modes (window,scaled,fullscreen) - color depths (16,32 bit screen mode) - and blitz3d: 2d/3d mode - and blitzplus: loadimage memory flags (managed(ram+vram),dynamic(vram),scratch(ram)) looking at the results for blitz3d: 1) the only memory reduction appears when the graphics mode is fullscreen in 16-bit. all bmp's are upped to the screen colordepth. 2) also, i think that if ur desktop res is set to 16-bit, all loaded gfx are adjusted to 16-bit, e.g. same technique as for fullscreen. (so if desk = 32 bit then window mode = double gfx mem) looking at the results for blitzplus: 1) the same 16-bit thingy happens as in blitz3d which halves the memory use when in fullscreen at 16-bit colordepth. 2) animimages (!) cause a major memory reduction (compared to single images) 3) load image memory type 2 (vram only) looks like blitz3d's memory model, while memory type 1 (ram + vram), which is default in blitzplus and memtype 3 (undocumented ),both support, and are affected by, BMPs (or any images) with a lower colordepth (like 2 colors). (yay) i've already ported one of my games (also robotix) to blitzplus, mainly for video compatibility, but it suffered some slowdowns not related to images. (due to Rects! lol) even though i used some complicated canvas setup, to re-enable the scaled window mode - which was removed for some obscure reason -the porting process was smooth and quick. seriously tho, my recommendation (also for myself ) is:- don't worry (too much) about vram usage - make the game in a runable state (so it doesn't crash) - and perhaps most importantly, focus primarily on ur own enjoyment and now, for fun (and indication), here are the results.. the output from the test program: and here's the test program: if u also want the images i used, ask away 
|
| Sat, 26 Feb 2011, 18:15 | |
|
j\\'ordos |
I figured I wouldn't be able to make myself clear from the start again excellent effort though! What you describe as the bullet starting from a different offset is defined in my program using the angle_start[] array, and the direction it will be traveling in (which I indeed want to change) is set by angle_travel[]. The solution you described would not work correctly: suppose I have a barrel that shoots straight, angle_travel would be 0. Then I would do ship_angle + 0 = ship_angle. If I then were to use the accurate sin/cos tables the bullet wouldn't travel exactly where the ship is pointing at, it could be up to 8 degrees off! So what I want is something like but then in a correct, working way (Sorry about angle_difference, I did mean angle_travel. )edit: to clarify, barrels and bullet spread are already working ingame, but they are limited to the 9 degree intervals used for the images, whereas I want them to be free of those constraints, but only the barrel's own spread! The ship angle should be kept at 9 degree intervals. Thanks for the in depth analysis (way too in depth ) on video memory! You're right that in full screen mode blitz3d does load images using whatever color depth has been passed to the graphics command, greatly reducing memory usage. (about 15 megs in 8bit mode - though my new system didn't display anything in that mode, just a black screen)That means there won't be much to worry about since older systems will probably have their windows display set to whatever their gfx card can handle. 8Mb gfx card users will be out of luck though edit: btw, in your IT file, some of the 'pages' (sorry, not familiar with tracker terminology) are called '+++' in modplug, whereas they normally just get a number. I think blitz3d crashes at the time it gets to one of those 'pages'. edit2: I also have an image editing related question: I want to create an overlay for the little weapon icons so that it's clear to the player how long his bombs will be recharging. For that I was thinking of using something like the old command&conquer build 'clock', where the image is grayed out and gradually becomes visible in a clockwise fashion. I think dithering will work fine (one transparent pixel - one gray pixel- another transparent one, etc) but is there a simple way to create such an overlay in an image editor? I have photoshop or paint
|
| Sun, 27 Feb 2011, 14:08 | |
|
Teasy |
* icon overlay actually, i have used both - a dithering mask fade - as well as a checkerboard mask (both at run-time) to either - make (part of) an image (or icon) transparent - or darken an image (or icon) the mask fade system i already have here on socoder: Linky (includes demonstration) which is probably more complex than what u need yeah, the clock-spin thingy would look like a nice effect on the icons indeed. actually, i disliked that effect in C&C1 but i'm very sure it'll look great (to me) in ur game haha. ( i prefered the dune2 percentage thingy in RTS games ) ( or some green, rainbow or colored progressbar ) the clock-spin thingy i've actually created in my game terra colony (probably in a render/visual BB file) the drawing algorithm for that is quite slow, so making images for that at about 5 or 10 degree steps should make it superfast. but, for simplicity sake, i guess the most simple way is, for example, using a checkboard mask - this can be created at runtime - or can be a simple image, to be loaded. then, for illustration, without the clock-spin thingy, simply having a fill-up from bottom to top. multiple ways again, one that's convenient is: - using ViewPort - and then TileImage. or one that's ultrafast (but more work) is: - using DrawImageRect - and making sure the mask is align properly. i recommend #1, which is easiest if u add the clock-spin thingy, i'd use an intermediate/buffer image. say the checkerboard image is white/black (or grey), then make the buffer image's mask black. and finally the clock-spin images can be in purple/black, having a purple mask (255,0,255). first draw(block) the checkboard on the buffer with a varying x offset, toggling between 0 and -1 each frame, which gives the illusion of true transparency second, draw(image) the clock-spin image (of ur desired angle) on top, with the correct alignment (centered), - which would leave the area under the purple color intact - - which turns into a transparent portion - while the black color would erase - . the other transparent portion underneath, which will make the desired portion of the original icon completely visible. finally, draw(image) the buffer image on top of the icon. here is some code that i used in robotix, which i use to make the background (behind hud gadgets) transparent: tiles64 is 64x64 image where frame 3 contains a simple white/black checkerboard (pixels). but this can also be runtime generated ofcourse. during the game, this is some example code u could use to make an image transparent: * blitz's fmod + tracker formats the '+++' (and '---') i use to neatly separate song sections which is 1 of countless things that make blitz3d crash. normally '+++' means 'skip this' and '---' means 'stop here' or 'go back to start'. u can simply remove the patterns from the orderlist after the first patterns that are played. e.g. turning this: (i don't remember what it looks like) into this: tho i guarantee it won't stop the crashes * barrels 'o fun (doom2 map23 )well, i'm gonna assume (again) that the spread you mean are barrels like these: (top down view) either, where the travel direction is different (?) from the barrel's facing dir. or, i can assume that u mean that the bullet spawn position on each barrel, is relative to the center ship position. ( so angle_start is 'bullet spawn offset angle' ) and that the travel direction is independent of the bullet offset. ( so angle_travel is 'bullet direction' ) perhaps a pic to clarify if i'm following correctly: pic 1 pic 2 i dont see how the javelin (  ?) (jvroll)can match any of the above barrel specs perhaps i'm nitpicking ( realism/practical pov ) so, i assume u mean pic #2 where the side barrels have a different length (longer) than the barrel in the center. ( lines "C -> o" should make a circle (of rays) ) ok so this means: so specifically for the bullet spawn offset: the easier part is fixing the accuracy, as u would like it to be actually, looking at the code from my previous post, it looks like it already does what u want. u just have to fill in the right variables. combined: this code can also be compacted ofcourse. i personally prefer putting code clarity before execution speed unless it greatly degrades the performance. perhaps u prefer the use of sin/cos straight up, without the use of the vectorx/y functions. i'll try translate bullet x note that i've added ship_speed sooner than in ur prog. so u can leave the ship_speed out, and add the ship\s to the bullet\s as currently happens in the prog, which is the more direct approach. i'll try translate bullet vx for fun i may have made a mistake in my translation, but the original code should be good in the origina code, i have assumed that: - ship angle is rounded (to 9? deg) - bullet spawn angle (pos) is exact (not rounded) - - but added to the (rounded) ship angle - bullet direction (travel angle) is exact (not rounded) - - but added to the (rounded) ship angle well, that's quite a story again i hope u enjoyed it i always like your puzzles hehe
|
| Sun, 24 Jul 2011, 16:51 | |
|
j\\'ordos |
Well it's been a very long time! But I'm still working on my game sometimes Recently I hit a new problem though so I decided to call out for help again. I was implementing a map screen, which pauses the game, so I had to make sure all the timers I have running are paused as well. Since Teasy posted a timer lib a few posts back which offered that functionality I converted my code to use it. But now my game crashes when I try to create a timer type from that library: This is my own code, it calls NewTimer which is a function from Teasy's library that creates a new timer object. The Newtimer function, blitz debugger highlights this line when it crashes with the message 'Object does not exist'. The function was modified by me: I replaced the global millisecs var used in the library with one I was already using in my program (FL\CurrentTicks). The FL type is global, and replacing that parameter with a constant did not solve the problem. And lastly the function NewTimer() calls. Any ideas? Regarding the bullet spread in the above post, I was still unable to get it working correctly, bullets still spread in 9 degree intervals instead of going off in any angle. I have to admit only tried the compacted, 'translated' code though, couldn't bring myself to use the drawn out, full code Also, does someone happen to have good ideas on how to code a function that regroups an AI formation that has been scattered? |
| Sun, 14 Aug 2011, 15:15 | |
|
Teasy |
Awesome, dear j\'ordos I can't see from the code you posted why it shouldn't create a timer object. I have not experienced any such problems with the library unless when integrating with other systems ( ),which I 'predict' is what is happening here too. If you could wrap up all the files etc as an archive and upload it somewhere, I will pull out my debugging 'crowbar' and take a look at it A simple work-around is simply letting all the 'times'* run when pausing the game, and subtracting the pause-duration from each 'time'* only when continuing the game. (and prevent any 'times'*/events from being updated while the game is paused) * By 'times' here, I mean simply a 'derived relative reference' to the current MilliSecs(), for example a single integer field to track the duration of an explosion. ...wait a bit (before pausing game) any/all events are ignored when game is paused ...wait a bit more (while game paused) Actually, 'drawn out code' usually give best results for me I have many programs where I didn't even optimize it because I considered it to be fast enough And ofcourse the benefit of being able to - read, understand - and edit the code more easily/comfortably. Anyway, that's my experience. I'm not sure how you want your AI to regroup as I can think of a multitude of ways. The first 'logical' method I think of is: - calculate the 'depth point', e.g. the (weighted?) average or mid-point inbetween all the ships/craft. - then all move to there - and wait until all have arrived - then take the next action from there. The first 'tactical' method I think of is: - calculating the next 'near point of attack' (or defense), - then all moving there - and waiting there until all have arrived - then attacking from (or defending) there. I haven't noticed this update sooner, so I guess I'll send you an email too
|
| Tue, 16 Aug 2011, 04:46 | |
|
j\\'ordos |
Excellent, I feared I wouldn't hear from you again! I uploaded the latest version here: users.telenet.be/V776822/Project/release.rar. I'm not sure what's new since the latest release, I added the bass library using midi files since I wanted to try out soundfonts, but that's mostly temporary. The workaround you describe is simple and effective but I would have to make sure I update every timer, with your library I'd only have to do a for each timerobject loop to get them all so it's a bit more fool-proof (provided I don't want any timers still running while the game is paused!)You're ofcourse very right about the drawn out code vs compacted code, bad habits die hard. I don't need a tactical method for regrouping the ships, a simple one will do, but the ships that arrive first should not keep flying in circles until their teammates have arrived as well. That would look very bad. Not sure if it can be avoided though, some ships will always have to wait but it shouldn't be too noticeable to a player somehow
|
| Sun, 28 Aug 2011, 17:32 | |
|
Teasy |
* debugging SpaceWars: bass_midi the first thing i noticed when starting the program was that the BASS.DLL and BASS.DECLS were not included but were still used in the program, unless ofcourse i have missed something (perhaps you moved something in the bass library?) so anyway, i've simply put those files in place (2 dlls & 2 decls) and it works, yay! i've noticed that, in contrary to bass_midi, the bass_mod (module/tracker) library (BASSMOD.DLL) seems to be entirely standalone (1 dll & 1 decls). * debugging SpaceWars: soundfonts while debugging/chasing the NewTimer 'bug', i also found a message 'error loading soundfont.' in the debuglog - maybe it means something to you i do not see a soundfont file located in the place where the program wants it to be ( or anywhere else in the zip ). * debugging SpaceWars: frame limiter ah, i have found the culprit! it appears that you have altered the reference to MilliSecs ( the global variable ) to become FL\CurrentTicks. ok so anyway, the culprit is the init 'order': NewTimer is called before the object FL (frame limiter) is created. simply moving the FL init code above the Ships init ( which is the first call to NewTimer ) should do the trick. * debugging SpaceWars: portability i have also included (further below) a new version of the timer library (4c) which is more robust, accurate, versatile and feature-rich. perhaps it saves some time to just put MilliSecs = FL\CurrentTicks in the main loop btw i am happily surprised that u have taken full advantage of most of the timer library functions * debugging SpaceWars: no weapon, no timer after moving the FL init code up, i noticed that TimerState is called somewhere before the timer that it wants is created. the first time it happens is on 'sh\reload_gun', probably because the ship has no weapon (?) ( looking at the Newship function ). fixing that, the game runs, woohoo! ( the music was VERY loud and scared the crap out of me ) * bass midi volume and so, the music plays fine ^^ ( without custom soundfont ) i've also found a way to change the midi play volume, using BASS_MIDI_FontSetVolume( handle , volume# ) where volume ranges from 0 to 1. and i see that the BASS_MIDI_StreamEvent function supports settings the global volume and mix level even using the MIDI_EVENT_MASTERVOL and MIDI_EVENT_MIXLEVEL flags. Global volume: 0(silent)..16363(full) Mix level: 0(off)..100(0db,normal)..200(6db,amped) and i found the reason why it was so loud; simply because the main audio output (in Windows) was wrong ( it changed, not sure why/how ) and bass_midi seems to emulate midi through wave so the entire midi music is being sent as a wave stream to the selected (primary in this case) soundcard. well, that's pretty cool actually, because this means a lot of 'inhouse' control over all the midi stuff. * modified source code so, after changing that (in Windows), everything in your game is perfect again i have included the modified source at the bottom of this post, so u can try it out and see ( if needed at all ). * original music after having read your previous post here, i was thinking about a bunch of thing related to your project, and another nice tune appeared (in my mind). so i decided to make another one related to you/your project it's called "On a roll". while working on the track i wanted to try compact it to under 128Kb without losing too much quality, and i've succeeded indeed! ( it was quite a bit of work i must admit ^^ ) * music demo with bass_mod and timer_lib upgrade i've created a demonstration program with it that uses the compact BASSMOD.DLL to play the file with more accuracy, stability and control. while working on the code i needed some timing and found some missing feature(s) in my timing library, so i gave it an upgrade (backwards compatible). i've added a new example program in the library (example5) which demonstrates every single feature (i think). ( the 'changelog' is at the bottom of the library code ) also, this music demo (for "On a roll") also demonstrates many timer features, as well as how to use bass_mod and an implementation of music timing ( also pausing ). i've added some pics that reflect that atmosphere of the music and to demonstrate the music timing in a nice way, while being a 'real' music (coder's) demo. the funny part is that the pics (5 JPGs combined) are much bigger than the music ^^ also, i've included the newest versions of some other libraries that i also used in the program ( all backwards compatible ). * music demo package so i've wrapped up all of that in another zip file for you ( or anyone who is interested and still reading this ^^ ) which 'incidently' uses the same 'style' as your SpaceWars, and i've also included an EXE just for convenience. in the INC dir i've added some more infos on bass_mod ( in help.txt ). Download: On a roll - Demonstration * continuing with SpaceWars btw, the music you have added to your game fits the game really well in my opinion/ears. and i'm inspired to see the ease with which you have implemented the bass_midi system i hope that you will be able to get the game running in the way that you desire, in combination with the ease of my timer library functions * formation regrouping for re-grouping the ships before a joint strike, perhaps do allow ships to fly in circles (or simply idle) while allowing them to engage targets within a certain radius. but if a ship exceeds that radius let it return to the 'meeting point'. looking at your code it seems that the formation has a state while a ship itself simply follows this state/action. one implementation would be for a ship to have its own 'substate'. for example while a formation has the state/action to regroup ( e.g. formation\state = state_regroup ) a ship can then be in 2 (or more) modes/substates: 1) idle: go to or fly in circles around/near meeting point. 2) engage target: if any enemies enter a certain radius .. ( call it 'regroup radius' ) .. chase this target individually. .. but keep checking radius while engaging, .. and go back to 'idle' mode when exceeding radius, .. e.g. moving back to 'center' .. and 'flying in circles'. Code additions: in essence, a formation's state would always override a ship's individual state. so, when all ships in the formation group are within the same (regroup) radius they can then advance to a joint strike, which would be a formation state i guess ( formation\state = state_attack ). i can't find your current algorithm to find the regroup or 'meeting' point, but i guess it can be calculated simply by finding the nearest 'regroup distance' away from the joint strike target without any other targets in a certain radius. here's a picture for illustration:  if you would like the entire formation to regroup without having a predetermined target, the same technique can apply (engaging as individual), but simply using the nearest position (average of ship positions) as the meeting point. here's another picture to illustrate that:  well, i don't know how or if this fits with your algorithms but i hope it gives you some idea(s) or solution(s) to easily implement your intentions. btw, i am truely amazed by your current code for all the formation AI etc, because it is way ahead of any formation AI i have ever implemented in my games it's always so great to see it in action! * modified source code SpaceWars4-tc1.bb:
|
| Fri, 02 Sep 2011, 16:19 | |
|
j\\'ordos |
Thanks for the help TC, I've spent some time fixing the remaining bugs in implementing the timer lib and everything seems to be running fine again now! I've also made some progress on the map screen (activated with the space bar), but zooming in and out (using the mousewheel) isn't working very well yet: the ships don't resize based on the zoom level (it uses the drawship function you wrote to test the ship 'rolling') and I need to find a way to let the player change the zoom level gradually (preferably using the mouse scroll wheel), currently it's pretty jumpy. Ah, I forgot about the bass includes which I had to put in the blitz3d userlibs folder. The only way to make it work was by putting it there, I couldn't just use include within my game. Is there a workaround? It does make it harder to share my code. Glad you managed to get it working though! The soundfont it is looking for isn't included in the archive because it is just below 200Mb in size The program didn't crash so I didn't bother removing the code that looks for it.Thanks for finding the bug, it was me being stubborn again then Though I was sure I tried changing FL\CurrentTicks into a simple constant and it didn't help... Maybe it was the sh\reload_gun error I ran into then and I didn't realize it was something else? oh well. I'm using the updated lib now and I'm leaving the millisecs var in place I Just added a PauseAllTimers & ResumeAllTimers function.I'm glad you like the music and my implementation of the bass lib but as I said it's temporary, I don't really think midi files are a good choice, not even with a 200mb soundfont. OTOH tracker music can get annoying quickly, maybe I'll just use no music during battle? At least I'm sure to use tracker music between missions and in menus (thanks for the example and new music file, is there a reason to keep it under 128k? Or is it something like my desire to use compacted code? ^^ By the way, do you have a mod/xm/... version of the wayout tune you posted earlier?)I changed the Createbullet sub to use your drawn out code to get the bullet spread working, and it does indeed work. But it appears there is a rounding error, as sometimes a bullet will travel in a slightly different angle than the ship is pointing. In the code you posted earlier I can't see how it uses the 9 degree interval table for the ship's angle and the exact table for the bullet_travel angle, it looks like it'd use the exact angle for both? Ah, your solution to the regroup problem sounds very simple and effective, excellent idea! Anyway, here's the revised version: users.telenet.be/V776822/Project/release2.rar |
| Fri, 09 Sep 2011, 08:52 | |
|
Teasy |
[ modifications summary ] i hope u didn't do any (or much) modifying of the code because i did ^^ first off, here's a compacted list of modifications that i've made: - smoother game init/exit - - frontend, backend, music stop, etc - show/hide loading with DebugLoad setting - enlarged mouse area to trigger map scrolling - added more init/load messages - unified map scroll speeds (mouse/keyb) - added ability to speed up loading - - by using virtual dummy images - added space to switch from map back to game - overloaded imagescollide (crash free) - added more section separator lines in code - overloaded print function (independent) - - to account for buffer switching - - with hopefully seamless scrolling - also overloaded write and locate - moved some things on map screen - rewrote grid function twice - - now supports 2 colors - - and coordinates - added some more things on map screen - finalized map zoom and scroll - renamed Debug to DebugTargets - fixed bullet spread bug - use M to change music track - re-enabled auto music switch - added real fps counter/display - toggle vsync with V - toggle 'crawl lock' with C for a bit of a story, here's some more indepth info on some specific items. [ vsync & crawl lock ] i've added a crawl lock for debugging purposes, which simply slows down the game to see what happens. btw, toggling vsync also shows (as well as crawllock), apart from revealing laggy, inaccurate or unstable code, in which parts of the code the frame limiter delta time (or 'FL\SpeedFactor') is used in an inaccurate way, causing an undesired funny effect ^^ (e.g. to see how the game would perform on a super-fast or super-slow system) for example zooming on the map does not yet account for speed changes, nor does the thrust fires behind the ship seem accurately placed during a slowdown or speedup. [ stack overflow ] i've noticed a 'stack leak', when u gosub from main loop to map loop, then to exit map loop, u gosub to start of main loop again, which adds a recursion cycle. this is similar to when u call a "map" function from within the "main" function and then the "main" function again from within the "map" function, which leads to a stack overflow after about ~42,000 which makes blitz quit (!) without reason lol. (it used to be an error msg) with gosub, it seems to go to approx ~253,000 for 'infinite' recursion ^^ (with same 'instant quit' behavior) perhaps these are insignificant tho, as these numbers are so huge, pressing space 125,000 times seems enough the solution is ofcourse replacing a gosub with a goto if a 'return' is never reached/used. to make sure i'm not crazy i also ran the same test with a simple double goto call. and i see it easily reaching 500,000,000 without interruption or slow-down so that gives me some comfort regarding my sanity level [ imagescollide ] while adding some new map zoom code blitz crashed again with a 'memory access violation' on an ImagesCollide call. the particular collision happened between a ship and a bomb. i see that ships are 36x36 so that explains the crash ^^ (not 2-power; e.g. 32x32 or 64x64) i have 'overloaded' the imagescollide function with a safe alternative, so that i can run it without crashing [ mousewheel zoom* ] the map looks cool ^^ with all the activity visible during the game when spacing in/out. as well as intricate stats! i've noticed that when u move the map the zoom location does not take into account the map position in any of the objects on screen. so when u don't move the map at first and just zoom in/out, the zoom location is correct (same as formation position). but when u move the map a little, the zoom location remains fixed to the map offset (which is an absolute screen coord) rather than the relative map offset. i see that u have inlined every occurence of "(fm\x-mapx)*mapz" for example, so i don't know if u wanna be bothered about this (minor?) interface issue ^^ for clarity, i have marked the focal (zoom) point on the map with a red dot. while looking at that, i came up with a smart fix, by simply moving the dot to the center of the map which seems more logical to me. i hope that zoom interface type seems logical to you too currently the grid drawing function draws the lines with very low precision (due to the offset), so zooming in/out can have a 'jumpy' effect. ooh, i added a quickfix by just forcing all value conversions to floating point ( in the drawgrid3 function ) the "ships" (ship markers) currently do not change in size when zooming in/out. but perhaps that gives a real "'hud' impression", alongside the static-sized text. ah, and i've added page up/down to zoom in/out as well, alongside the mouse scrollwheel, in case some1 doesn't have one [ code share basslib ] When I discovered that you included the decls I thought: "Wow, that's very fancy indeed!". I often simply inline the decls' calls in the code ^^ I don't know of a direct or easy work-around for sharing your code with an external DLL. Alternatively, I included an EXE in the "On a roll" demo for those who don't like the hassle ^^ [ soundfonts* ] Wow, I'm a bit surprised by the soundfont size ^^ Most of my soundfonts are below 20Mb! Though, it makes me curious what that music would sound like with that 200Mb soundfont ^^ So I looked for it online, found it and downloaded it, hmm, it still sounds like a midi file ^^ i guess my expectations were a bit too high tho i had, and am, still having fun playing with all this stuff ^^ so thank you for providing all these goodies [ timer lib ] Great news on the quite flawless progress i'm glad you got the timer lib implemented to your liking/specs. And the Pause/Resume AllTimers is a clever idea! [ tracker music ] Perhaps tracker music during gameplay can be made less repetitive (or annoying) by playing different parts/style depending on the situation in the game, which is actually very easy with bassmod/lib ^^ Although this may seem like a 'pro' feature for a 'small' game to have (?) also, a bit of a deluxe feature is leaving the midi music support in, perhaps with a standard or custom soundfont placed in the 'soundfonts' folder. and alongside that, adding support for tracker music ^^ i don't know, just an idea [ small mods ] Yes, the secondary reason why I was making the modules so small, was because you mentioned before that you liked small sized files/packages/games etc. (as do i) But the primary reason why I'm making them so small is simply to see how it sounds and if it is possible to make it sound good or perhaps better than some ancient MODs ^^ I got the OGG version down to 360k ! ^^ (with acceptable quality) [ way out* ] The original wayout1a.it module weighs in around 5.6Mb, using about half of its included samples. I also have a newer version available, from Jan 2011, which I will include. I will strip all other sub-songs and unused samples also. after compacting the music module in various ways: - removed unused patterns in orderlist - removed unused samples - removed unused instruments - removed silence and unused parts from samples - downsampled samples without much quality loss - shortened long samples by making new loops - converted 16-bit samples to 8-bit (509KB) - resaved with impulse tracker 2.14.5 (303KB) i've been able to reduce its size by about 1859%. i've also modified the onaroll demo to become a simple unified bassmod player to test the compatibility, working and sound quality of the module. along the way, i've stumbled upon a few strange bassmod limitations for which i've created a few work-arounds. i have uploaded the package with track and code here: This is the way out (music module) & a simple bassmod player (with code) note: the player supports specifying a custom file on the command line. [ bullet spread* ] Ooh, I'm relieved to hear that the drawn-out code works ^^ well, i think i've found why the bullet spread thing worked almost as good as you hoped it would ^^ it seems i added the ship speed to the bullet speed too early in the algorithm. so i moved it to a later addition and i think that should do it. but i'm a bit unsure if this is the right thing because i don't know how to test it properly lol. anyway, i've changed this: into this: i've replaced it in 3 locations in the code (in the CreateBullet function). i don't know how the CreateBullet_Turret relates ^^ [ regroup ] Okay, I'm glad we're on the same page about the regroup solution, and that you're happy with such a simple solution well, i hope you're doing well and having fun along the way ^^ (btw, we can also use something like Assembla to more easily simultaneously edit the code) [ sourcecode ] here's the new (modified) source code.. as an easy download version: SpaceWars V4 of 2011-09-09 and inline: spacewars4-tc5.bb
|
| Fri, 09 Sep 2011, 17:48 | |
|
Teasy |
hey ^^ i felt like expanding on the 'wayout' track, so here's a song with 3:30 duration that also loops endlessly and with some nice variations. This is the way out (music module) s4v2 this one's 5KB bigger than the previous one which was 303KB, having 4 subsongs with short duration. well, enjoy and have a good one
|
| Wed, 14 Sep 2011, 16:40 | |
|
j\\'ordos |
Great work TC!! This is another great step forward and a huge help for me . I finally took a look at what was going wrong with the exhaust flames, which was something that has been bothering me for quite some time, and I think the problem was that I multiplied the starting velocities of the flames with the FL\SpeedFactor variable. After removing that they seem to be working fine. About the stack overflow, I never managed to crash blitz by using gosubs like that before, and I did it a lot in some of my previous projects too. Didn't realize that doing so was bad programming A simple goto is ofcourse much better anyway, don't know why I didn't think of that.Ah I forgot about the ImagesCollide crash again, sorry about that. Though there shouldn't be an imagescollide call for the 36x36 fighter craft, I'm using VectorDistance to detect a collision there. Only capital ships use imagescollide and I made sure that the images they use are all a power of two. I wonder what's causing it. Excellent work on the map screen, it looks a lot better and now that the zoom is working correctly I indeed no longer mind that the ships are drawn the same size for each zoom level. And ofcourse good call on moving the center point of the map, it's much better! Allowing both midi music and modules is a good idea, and dynamic music would be especially cool I think the soundfont is a great improvement over the original files, but perhaps you have a better soundcard, I'm just using onboard audio? Slapping on a 200mb soundfont kinda defeats the purpose of using midi files though Thanks for the updated track and example files, I haven't looked at BASSmod yet, but they will be very useful once I feel like working on that part Unfortunately the bullet bug is not fixed with your latest code. I added some code to display the player's current angle, and it showed that at 181 degrees (ship points straight down) the bullet travels in the correct direction, but at 183 degrees (ship still points straight down) the bullet travels as if the ship were at the next 9 degrees interval, which is not correct: 181/9 = 20,111... and 183/9 = 20,333. Firing bombs does work like it should. The Createbullet_turret sub is exactly the same as the createbullet sub, but for turrets (duh). It uses the turret pointer instead of the ship pointer, but otherwise it's the same. (although I haven't added the bullet spread code to it yet) I actually thought of another way of dealing with the regroup code, which I'm working on right now: instead of moving all four ships immediately towards the center point of the formation I first subdivide them in groups of two. Only once a 'subgroup' has regrouped will they move towards the center point of the formation. With only two positions to take into account there should never be a case where one ship has to wait for another. I'm fine with using a project space but I've never used something one. There are multiple free options to choose from at assembla, which one should I choose? edit: also, I added a clock display (it's in the update_ui sub) but it's not displaying the correct time. I got it from a code archive. Any idea what's wrong with it? |
| Wed, 21 Sep 2011, 20:11 | |
|
Teasy |
hey good to hear your news, j\'ordos here are some more things that i'd like to share with you which may be helpful in some way ^^ starting with the lighter topics and going up to the more heavier ones. * sound font well, in this pc i have both an onboard and an offboard 'chips on a plate' (card). windows (xp) allows me to set the default midi playback 'device', which then sends it to either of the cards. for both of them i can 'select' a custom (default) soundfont so that any midi's are played through that. for example, i have a soundfont that's almost identical to my old awe-32 card, so i just select that and all (standard) midi's will play through that. there are (/i have) many 'general midi'-'compatible' soundfonts ( full set of instruments ) that are small and (to me) good-sounding. * imagescollide hmm, i see now that a 'ship' can also be an 'escort' which is 169x169. ( e.g. not power-2, crashing this gf8600gt ) i don't know the speed of the overridden ImagesCollide function, but if its speed is sufficient on your good'ol trusty pc ( i have one here too )perhaps it saves a lot of hassle just to leave the 'lifesaver' function in place and pressing the 'set it and forget it' button ^^ * clock i was wondering btw.. what do u want the clock to display? the time since the start of the game? or perhaps the current time on the computer? for the 1st (game start) you could do this: although, i personally prefer this (for the game start): with some string function ^^ (re)updated here: - socoder.net/index.php?snippet=8132 but, if you want the current system time: (without seconds) (or with seconds) * bullet code i think i don't understand how you want the ship or bullets to behave it's possible that i have misunderstood this in a previous post, or even in multiple previous posts ^^ maybe you want to illustrate for me exactly what you want and how you want it to look. particularly i'm a bit confused about how the bullet angle 'incoherence' you mentioned on 15 Sep 2011 relates to 'bullet spread'. i'm also curious about your understanding of a 'turret' and how that relates to your intended 'bullet spread'. i think with some additional clarity this should be much easier to resolve * regroup ah, yes, sub-meeting points.. that's so wonderfully clever ^^ that made me think.. if there are 3 ships left (instead of 4), (or perhaps more than max 4 in a group?) what the 'odd' ship would do (3rd, 5th, 7th, etc). the first thing that came to mind was a recursive algorithm (^^) to let each nearest fighter pair meet up ( can insert math-intensive algo's here ) and letting any 'odd' ones trail the nearest 'pair'. from there, each pair meets the nearest pair, all the way up (double pair, quad pair, etc) until all ships in a group have met, whose rendezvous points can also be plotted along an interpolated path towards the next target. i think there's also a very difficult name for this in the academic math science thingymabob to describe a form of smoothing (perhaps 'binaural interpolation'). perhaps not needed at all if you have max 4 ships per group anyway. but i thought it was a funny idea so i thought i'd share anyway ^^ * assembla/subversion well, i have 2 things over there i think, which i/we added, like, a 'while' ago. but i think i remember a little bit how it worked. hmm, it seems they have commercialized the place many features seem to be 'stripped' (?) and something about 'free for 1 year' lol (?) on www.svnhostingcomparison.com/ i see many alternatives in the past i've always used something called 'subversion' (SVN) for 'intermediation'. but perhaps there are improved versions now. before, it was as easy as clicking 1 button everytime i finished making final changes to the code. i see the following sites as primary candidates with many handy features (some are 'public' only): - springloops, 1 project, 2 users, 100 mb (git,svn) - unfuddle, 1 project, 2 users, ? mb (svn) - fogbugz, 1 project, 2 users, * gb (hg,svn) - myversioncontrol, 1 project, 3 users, 100 mb (svn) - xp-dev, 2 projects, ? users, 200 mb (git,hg,svn) - riouxsvn, 4 projects, * users, 50 mb (svn) - projectlocker, 3 projects, 3 users, 300 mb (git,svn) - kenai.com, 5 projects, 5 users, ? mb (git,hg,svn) - launchpad, * projects, * users, * mb (bzr) - gitorious, * projects, * users, ? mb (git) - github, * projects, * users, * mb (git) - berlios.de, * projects, * users, ? mb (git,hg,svn) - google code, * projects, * users, 2 gb (git,hg,svn) - sourceforge, * projects, * users, * gb (git,hg,svn) - (ms) codeplex, ? projects, ? users, ? mb (hg,svnbridge) - bitbucket, * projects, * users, * mb (hg) - origo, * projects, * users, 10 gb (svn) [ ? = unknown/ample, * = unlimited/ample ] i've just done a little research on modern versions of 'subversion (svn)' and 'git' (git) seems to be the "new best" followed by 'mercurial' (hg). there's also 'bazaar' (bzr). for a subversion client, it seems that 'tortoise' is available for all 3 flavors: - tortoise svn -> subversion - tortoise hg -> mercurial - tortoise git -> git and/or commonly used (on windows) for repositories. i think that svn/hg have better support for windows while git is particularly 'popular' on the unix-like systems. i think i would pick 'svn' just because of its simplicity ^^ and i also like a host with a wiki so it seems like i'd probably pick google code (or sourceforge) for svn, or perhaps bitbucket if the 'algorithmical' benefits of mercurial (hg) are desired ^^ or 'github' for the ultra-tech 'git' 'protocol'. here are all the links that i've used for convenience, if needed (in same order as above) Springloops - The web development collaboration studio - www.springloops.com/v2/index.php Subversion Hosting, Git Hosting, Project Management - unfuddle.com/about/tour/plans FogBugz On Demand Sign Up: Student and Startup Edition - shop.fogcreek.com/FogBugz/default.asp?sCategory=HOSTEDFB&sStep=stepEnterEmailAddress&HFBnForm=1 myVersionControl - Subversion Hosting - www.myversioncontrol.com/prices/ Subversion, Git & Mercurial Hosting, Project Tracking, Trac Hosting & Agile Tools - Pricing - xp-dev.com/pricing RiouxSVN — Free, Private Subversion Hosting - riouxsvn.com/ ProjectLocker: Free Subversion Hosting, Free Git Hosting, Free SVN Hosting, Free Trac Hosting, Software Quality On Demand - www.projectlocker.com/ Project Kenai Documentation and Training: Wiki: KenaiOverview — Project Kenai - kenai.com/projects/help/pages/KenaiOverview Commercial subscriptions and joining Launchpad — Launchpad tour - launchpad.net/+tour/join-launchpad About - Gitorious - gitorious.org/about Plans & Pricing - GitHub - github.com/plans BerliOS Developer: BerliOS Developer Services - developer.berlios.de/docman/display_doc.php?docid=26&group_id=2 Google Project Hosting - Google Code - code.google.com/projecthosting/ sourceforge - sourceforge.net/apps/trac/sourceforge/wiki/WikiStart CodePlex Information and Discussion - codeplex.codeplex.com/ Free source code hosting — Bitbucket - bitbucket.org/ Origo | Origo - www.origo.ethz.ch/ so, to summarize, for a 'straight-forward' solution, reg + create proj/repo @ google code and install turtoise svn. ( i think ^^ ) then it should be a 1-click operation to 'get' or 'send' new sourcecode updates. perhaps something else has your preference or attracts your 3rd eye's focus? ^^ orrrr... <daring/bold prediction> considering the stuff occurring in the next months </> just reg with assembla without the extra options ^^ ( if that feels right for u ) well, if u need some more help with this subversion stuff, just lemme know in the meantime, <offtopic> i will be doing some more meditation end emotional clearing to transmute any disharmonic frequencies on this 'Earth-ship' ^^ for noticeably improved balance, stability and agility. i hope that you, dear j\'ordos, (and ofcourse everyone else on this forum or reading this) will greatly enjoy this ride and be able to utilize your very unique and most remarkable talents and abilities in any situation that will arise (most notably the intent to improve the life of everyone involved - not forgetting our own) </> much love (3
|
|
|
| |||
|
| ||||