123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|683|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> some help with a space shooter

Page : 1 2 Prev 3
Next
Sun, 26 Dec 2010, 04:56
Teasy

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

Page : 1 2 Prev 3
Next