Would you pay for it? and if so how much?

. No more time to waste .

Absolutely.

Probably not, since the only interesting module (to me) is the projection matrix stuff, and thus buying a whole suite seems a bit exsessive.

I definately think it's a good idea, but it seems your modules are a bit too specific, and not generic enough to warrant a 'suite'.

If I did need all the modules I'd pay anything upto about 100USD without a second thought.

I'd pay for a nice cross platform printing module.

Steve.

Hmmn, In what way are they specific? They cover all areas with regard to game making.

@Steve, what are you wanting to print?

How about a low price for each separately then several related ones clustered together for a 3-5 pack then a mega pack of the lot?

For anyone who is serious, they can save loads of time and thus money by buying in decent working source that someone else has slogged over and worked all/most ;-) the bugs out of.

Do you have example apps with each module? I'm sure you do, but that's cool too as people love examples.

It really depends on how easy it is to use such modules. If they were to come with very good documentation, I would pay $100.00, if no documentation at all, $20.00 but ONLY after reading enough reviews on the said product to ensure I could even use it.

For me, being able to use the product, and being able to use it creativly, makes it valueable. Tutorials would make it worth a lot to me... alot!

Anything really. Text, images. Print Preview.

It would be nice to create a virtual page in memory and then use any of the 2d commands on it before printing/previewing.

Half those modules you listed would not be of much use to me right now, but they may come in handy in the future. What sort of price are you thinking for them?

Steve.

Yes.



No, since none of that is of any use to me.

$15.00 USD Each Module, or $50.00 USD All Modules

My DLL will have printing and ADO all in one... But obviously it'll be windows only.

Not sure If I will sell them or give them, if I give them then they will have minimal docs and no support.

@Grey, I have examples which I will post depending on what I decide to do.

@Matt, That's Fair, If I charged you I'd make sure you knew how to use the stuff.

@Noel, niether are yours :P

@Wayne, Send me your money.

@Mystik, no idea on price YET. Printing is not something I need so I'll probably leave it.

Isn't RC4 proprietary?

I ain't charging for mine though ¬_¬

No, because then I had to buy BlitzMax as well... :) I'm sticking with the Blitz3D for quite some time before purchasing any another language... which might be something other than BlitzMax when the time comes.

shame you can't use futuremark's engine with something high level like lua to script the game...

@ Malcolm, Yes the alogorithm is. The module has other stuff which increases the capability.

@ Noel, niether am I yet :D

@ Mustang, interesting point.... All of these except for A* were first developed on B3D and are used in all our games.

@1-i-jack, What??

Edited Thread.

Well that's certainly debatable.

From what I can tell, only useful if you make extensive use of AnimImages - which may not be the case.
Depending on how it works, may be generally applicable.
Again, depending on how it works, may be generally applicable.
Only useful if your game data is structured as a dense graph.
Only useful if you want to work with polygons.
Useful as a silver bullet for making your game more resolution independant - generally applicable.
If it's a strong implementation, only useful if you need RC4 encryption.
Only useful if the built-in sound support isn't good enough for you.
As above, mostly useful if you're doing that polygon thing.
Only really nessecary if you need higher than MilliSecs() resolution and accuracy.

So most cover very specific areas of game making, and there are quite a lot of areas yet untouched by your modules. It's not that I'm blaming you or anything, maybe you just focus on another type of games than I do.

Also it's not that I'm having a go at your work, which I think is rather remarkable - its just unfortunately (with a few notable exceptions) not what I'm looking for right now.

To be fair, the XML module (although I haven't tried it) certainly has its uses. If it works. :o>

Here is my take.

- AnimImageFast (Single Surface Image Drawing)
From what I can tell, only useful if you make extensive use
of AnimImages - which may not be the case.
** It's great for things like Particle engines and graphics that have a similar size. Did you know that BMAX creates a seperate surface for each AnimImage!!!

- bMapText (Single Surface Bitmap Text Library)
Depending on how it works, may be generally applicable.
**It does what it says on the tin.

- DeltaTime (Pre build timing module)
Again, depending on how it works, may be generally applicable.
** Agreed

- Indie_Astar (A* PathFinding 2D)
Only useful if your game data is structured as a dense graph.
** Agreed

- Poly (Full Polygonal Suite for Vector Graphics, scaling, rotation and collision hulls. Integrates with TexturedPoly)
Only useful if you want to work with polygons.
** Actually no, you could wrap a sprite with a collision hull and have mega fast near perfect pixel collisions.

- ProjMatrix (Projection Matrix Handler with zoom and rotate)
Useful as a silver bullet for making your game more resolution independant - generally applicable.
** Aye.

- RC4 (RC4 Encryption and Decryption)
If it's a strong implementation, only useful if you need RC4 encryption.
** Great for storing highscores, player data etc on disk.

- SoundLib (MultiChannel Audio Management Library, Loop sounds, Queue Sounds, SingleShot Samples , Fade in and out etc.)
Only useful if the built-in sound support isn't good enough for you.
** This is adding to the existing support and is build around the sound module.

- TexturedPoly (Draw Textured Polys with any Image, includes GlowingLines)
As above, mostly useful if you're doing that polygon thing.
** Yep

- Timers (High Resolution Timer Module)
Only really nessecary if you need higher than MilliSecs() resolution and accuracy.
** it's a Millsecond timer but you can run 100's of them.

These modules have been used in some shape or form in all our games. GEOM for example uses 8 out of 10 on the B3D Platform.

sure... i'd pay for a decent 3D engine module...

:)

i'm a big supporter of supporting the development communities i frequent... my latest license was for PaceMaker, and i've licensed a few applications made by some of the devs here...

i would definitely pay for a well done module and the like...

--Mike

> > Would you pay for BlitzMax modules?
>
> Absolutely.

Not so long ago Flameduck I remember your "Code wants to be free" sig :)

You must have forgotten the bit about 'free as-in free speech, not free beer'. :o>

Free software is about the freedom to use software as you choose. It is not about not paying for the software in question.

There are lots of examples of free software with a pricetag, and non-free software without one.

he thought you meant free Edam...

--Mike

lol.

I'd pay. The $15/$50 deal Wayne mentioned sounds good to me.

Bring on the prices Indiepath!

I whant to buy them now!

Sorry, I still don't get this. What does this module do, exactly?

Very confusing 3D maths stuff, essential for any 3D engine.

I'd pay for modules, but none of these, as other people have said.

I may pay for all the Modules 20 Euros.
But I keep thinking you managed to hack the projection Matrix , you found a way to create textures in Max2D ...
Will the community gain more if those functions and methods stay closed and documented or if you open them to the public and explain how you managed it?

Also if you still using a modified nPoly for your poly module I have to say that this thing it's not good enought to make money with it.

How do you hack a projection Matrix? The matrix is well documented in the DX7 SDK, all I have done is implement stuff.


? Images are already textures??? I just using them properly :)

I Hate compiled modules too, but hey, I'm a businessman and I have my intrests to protect. Sure I'll give a few pointers and I'll even sell the source code if someone wants it bad enough.
Nope I'm not, it's a total rewrite, as of yesterday. Anyway what's wrong with nPoly? it's fantastic!

For nPoly the problem is it is for not fast moving objects or for very slow moving objects. The over all problem is that it uses only ray intersection collision check this may make it fast but also rare usefull.
Also the build in collision responce in the collision detection and the closed source makes it even more rare useful. Because is wand to make some more from it you can't. You just have the option to bounce.

I am not trying to be ofensive here I am just saying my opinion and I may be wrong.

In short, it 'projects' a virtual resolution onto your actual resolution screen.

It means that you can write your game telling it to use a 1024x768 display -- but by setting the projection matrix, you can project this onto an 640x480 or 800x600 or other size screen as well, without the need to rewrite any of your code. It automatically rescales everything to use that resolution.

Much easier than having your drawing routines and scaling calculate everything individually for each resolution. As far as your game logic is concerned, it always runs at 1024x768, when in reality it isn't.

Of course you game will look best in the "native res" it was made for. I would suggest making most games in 800x600 and scaling down to 640x480 or up to 1024x768 or more if need be. Lots of games don't have scaling, but it is a nice option as long as the graphics are scaled with a decent algorithm so they aren't horrid looking.

@Haramanai, I've built a couple of methods of detection, you have bounding box, circle, point-in-poly and intersection. Everything is worked from the collision hull so you can have really complex polygon collisions without impacting the framerate. I've not implemented ray-2-poly yet but I'll get to that.

The projection matrix scaling is done by your GFX card and GFX Drivers, this is hardware scaling not software.

OKay, there seems to be a big difference of opinion here.

Here is my suggestion(s) :

- Freeware License - No charge, no support, no sourcecode - acknowledgement of usage within game/application.

- Commercial License - Unlimited usage, full sourcecode and support.

Sounds sensible. You also need to make it 100% clear that if the game is to be freeware they buy your freeware licence and if it's to be commericial they buy your commercial licence (no freeware licence allowed). Of course people making freeware games may still want your commercial licence just for the source and support, but they can't have it the other way round i.e. commercial game gets freeware licence. I know this sounds obvious, but when I first read you post I was trying to figure out of you mean "your" freeware licence or if "their" game was freeware etc.

You wanna see the license agreement... Tight as a nuns....

... hairband.

lol

Small test of the PolyModule : http://indiepath.com/tim/vector_test.rar

Here's the code :

Import indiepath.projmatrix
Import indiepath.poly

SetGraphicsDriver GLMax2DDriver()

Graphics 640,480,0
'Graphics 480,360,0
ProjectionMatrix.Initialise(640,480)

SetBlend(ALPHABLEND)

Global BurnIn:Timage = LoadImage("screen512.png",FILTEREDIMAGE)
Global Dot3:TImage = LoadAnimImage("glowing_dot_64.png",64,64,0,4)

Global Ship:iPoly = iPoly.Load("ship009",100,100,$FFFFFF,1,ALPHABLEND,14,False)
Global Ship2:iPoly = Ship.Duplicate()

Ship.Scale(0.6,0.6)
Ship.VisSet(1)

Ship2.ColorSet($99aaFF)
Ship2.WidthSet(18)
Ship2.BlendSet(LIGHTBLEND)


While Not KeyHit(KEY_ESCAPE)

	Cls
	Local hull = False
	If KeyDown(KEY_H) hull = True

	SetBlend(ALPHABLEND)
	SetAlpha(1)
	SetColor 205,205,255
	DrawImageRect(BurnIn,0,0,640,480)

	Ship.Turn(3)
	Ship2.Turn(-1)
	Ship2.Position(MouseX(),MouseY())

	iPoly.DrawAll(Dot3,3,hull)
	
	TPoly._Begin()
		TPoly.GlowingLine(Dot3,0,300,100,500,300,20)
	TPoly._End()
	
	If iPoly.PolyOverlap(ship,ship2) Then 
		DrawText("PolyOverlap : Collision",0,0)
	Else
		DrawText("PolyOverlap : No Collision",0,0)
	EndIf
	
	Local rx#,ry#
	
	If Ship2.RayIntersect(300,100,500,300,rx#,ry#) DrawText "RayIntersect : "+rx+" : "+ry,0,20
	
	'If Ship2.PointInside(MouseX(),MouseY()) DrawText "Inside",0,40

	Flip '0
Wend

Since the source would be included I'm interested in the commercial license.

Ok sounds fair. Commercial license but don't make it heigher from the price of the maxGui...
I have another question.
Does the pathfinding works together with the poly module or it is a grid based pathfinding?
I konw that the basic A* it's grid based but think about it.
The projectionMatrix , the poly ,the texturedPoly , the pathFinding that works together with the poly and an editor to place nodes for pathfinding , texturedPolys and ....
It will be a great product.

It's grid based.

Ching!!! I just realised that with very little modification the poly module can be used to wrap normal images with a collision hull. Now your sprites can have fast and accurate collision detection, you even get the exact point of collision!

Looks like I need to now rework the Editor.

New Module Alert!!!

Lights2D : Utilise OpenGL or DirectX lights within your game.

I wouldnt buy it but I dont need them.

I'd probably be interested in a few of these.
Tricky to say how much as it'll depend on exactly what they do, how easy they are to use and how well they work.
Certainly wouldn't go to $50-100. Maybe $20.

Tim, Did you come to a decision with these?

Tony, drop me a line if you want them. I don't have the time at the moment to support them so selling is out of the question right now.

Will do... have done.

Job done.. :)

And that pants are now off.

Tim are you the only person working on BlitzMax? Hello? Sibly are you there?

I'm working on it too. Just not the 2D side.

What about the guys we bought BlitzMax from Noel?

They're working on Bugfixes for Max2D, MaxGUI, The compiler, looking at requests for new features from people and working on Max3D.

So in a sense they're quite busy.

[quote]What about the guys we bought BlitzMax from Noel?/quote]

They're somewhere around here. Being disturbingly quiet as usual. Nothing out of the ordinary, really.

if you dont want to or havnt time to support them then sell them very cheap as is.

or Open the Source

I will get around to selling them one day, perhaps!

For all the excellent hobbiest languages out there (everything bar c++) I am constantly frustrated by the author's lack of direction and sensible priorities. ie) we must ensure compatiblity with X minority computer system - hello? Windows PC/DirectX is paramount - stop wasting your time!

I think perhaps I should quit moaning and produce a language of my own. I'll only have myself to blame for the lack of progress and lack of direction (however big the challenge).

Respect to the guys that have produced such languages - but I feel that they really need to wake-up to the fact that there is one huge user base and program for that - end of story. If they do then I guess I have some serious competition, but I feel helpless when relying on others to make good decisions.

On a closing note and thanks to Mark Sibly for re-introducing me to programming, has anybody got any suggestions for a language name based around game production?

Many thanks,

Steve

Blitz3D? Doesn't suffer any problems with Macs, either.

I've decided that it's very unfair of me not to share the source. Give me a couple of days to get everything together, including a reasonable license and I'll release the whole lot with source.

**There will be commercial restrictions.

I'd be interested in these for Blitz3D. You said they were first developed in B3D, and so it shouldn't be that hard porting them back...

Good news, Tim.

@Steve, sorry I'll supply as is, you would need to convert back.