Qbasicnews.com

I always define Tiles as background, or terrain etc.. and sprites as things that block/move/shoot/whatever..

Tile = Grass, Sand, Mud, Stone, Whatever
Sprite = Tree, Player, Monster, Whatever



And seeing as FB is 32bit, why not simply use BMP's, or even PNG's/JPEG is space is an issue...

Instead of using the old BSAVE/BLOAD

Yup...
You could just use old QB to write a small utility that converts all your pp256 files into another format, like bmp. Then the palette problem would go away too.

Well it's not a question of size or limits per se. My question was, since FB is somewhat of a 32bit version of QB (I believe, correct me if I'm right ;-), or slap me silly with a wet noodle if I'm wrong) lol....but if it is, I would think a good suggest would / could be some standard means of doing what people currently do in QB. RPGs, TILEs, etc etc....3D anyone ;-) ?

Or at least, of not right now, sorta plan for it so it's "planned for the future" so that it may affect the produced code :-).

Interesting idea for sure. QB itself has a standard PUT methd for graphics, which virtually all QB libraries make use of. But since FB can use virtually any Windows-based library, you're going to have to go with what each one supports individually. My own experience with Windows graphical libraries (outside of the GDI, which I've used a LOT) is limited to OpenGL, DirectDraw, and TinyPTC, and of those three, only OpenGL has any real "standard" way of doing things. For TinyPTC, you have to write all your own graphics routines, as all TinyPTC is is like a virtual screen buffer...it comes with a plot function and literally nothing else...add your own sprite routines, primitives, etc. I based my TinyPTC extension library on all the standard QB routines, since they were what I was so used to...but you can do it any way is comfortable to you. I imagine FB is more than fast enough to handle BASIC-level sprite routines.

Quote:Well it's not a question of size or limits per se. My question was, since FB is somewhat of a 32bit version of QB (I believe, correct me if I'm right ;-), or slap me silly with a wet noodle if I'm wrong) lol....but if it is, I would think a good suggest would / could be some standard means of doing what people currently do in QB. RPGs, TILEs, etc etc....3D anyone ;-) ?

Or at least, of not right now, sorta plan for it so it's "planned for the future" so that it may affect the produced code :-).

Sterling is making an SDL wrapper that mimics the QB GFX syntax. Really easy to use.

Freebasic kicdks QB's arse when we talk of 3d rendering. You can use OpenGL, SDL(my choice), or dx. Plus you could probably port some classless wrappers like allegro.

If you plan do do some democoding, you could use TinyPTC. Here's an example:

http://rel.betterwebber.com/junk.php?get=29

Quote:Yup...
You could just use old QB to write a small utility that converts all your pp256 files into another format, like bmp. Then the palette problem would go away too.

there already is such a program. Someone from venosoft (can't remember who) made a utility that converts .PUT to .BMP.

I picked up a program like that somewhere on this board. Only problem with it is that it can't convert files with images of different sizes.

I went searching around and found this topic with a link to the program: http://forum.qbasicnews.com/viewtopic.php?t=6041.

There's another one out there somewhere, but I never got it to work right.

Quote:I picked up a program like that somewhere on this board. Only problem with it is that it can't convert files with images of different sizes.

That's easy to fix though.

This sounds like a nifty little side-project I can take up in my *cough* 'spare time' today.

ADDENDUM: Okay, after taking a looksee at the PP256 files, the APF and PAL files are 1024 bytes: binary-saved LONG arrays, ready for use in PALETTE USING. My program uses a TYPE to define this:

I've already just about finished with the palette routines and I've got the base structure for the graphic arrays set up. Now it's time to do the work of graphic import. This should be pretty easy, although somewhat time-consuming. Further addendums later.



ADDENDUM 2: Got the viewer working, time to integrate palette routines with it, then do the BMP exportation code. After that, it's done.



ADDENDUM 3: Palette integration working, as you can see from this image with a custom palette. I'm just toying with images from PP256's Images subdirectory for the moment, and all but one are of the same size (CHARSET3.PUT uses variable width graphic arrays and they display fine).

To Barok:

Quote:

Dr_Davenstein Wrote:Yup...
You could just use old QB to write a small utility that converts all your pp256 files into another format, like bmp. Then the palette problem would go away too.

there already is such a program. Someone from venosoft (can't remember who) made a utility that converts .PUT to .BMP.

Yes there is, and *yes*, it was from Venosoft indeed. I believe it was called “PP256 tileset to 8-bit Bitmap”, and Barok, when I tried it ever since I first picked it up in 2002-2003, it did such an excellent job at converting both the PP256-based sprites and the 1,024-byte palette of your choice to .BMP format as true a form as ever, albeit not perfect in only some areas. One of my surefire recommendations here is to pick it up and try it if you haven’t already. =b



And to DanKirby:

According to your reply, man, there was another program that converts PP256 sprites to .BMP format. And guess what, that’s right. It was called PUT2BMP by author Michael Dowling, and apparently the program must’ve been created in MS Windows using Allegro. I have tried it, and while it does a pretty good job at converting some sprites over to bitmap form, I sadly found it more *frustrating* to use than the program PP256 tileset to 8-bit Bitmap by Venosoft. Here’s why.

First of all, even though it does let you specify a wildcard ( * ) as a filename and an extension (which is a good thing! ), if you get the filename and extension even a little bit wrong, the program automatically exits abruptly (it is like “What’s up with that! :-? ”, you know?).

Secondly, while it does lets you transfer some of your sprites over to .BMP, it places them one-by-one vertically, which can cause a bit of frustration to some.

Finally, PUT2BMP needs pretty much a lot more work, in order for it to be as truly good as ever. I wanna wish Michael Dowling well on that, too!!

That is all I truly know on what I think of the program, man. For real. !



And finally now, to the rest of you:

If memory serves me correctly here, I can promply remember a program by DiZZy Productions entitled DiZZy’s Sprite Editor, which did a *marvelous* job at converting a lot of the 256-color .BMP’s (up to 100x100 in size) to PP256’s own .PUT sprite and .APF palette formats, respectively!! ^_- ! That really impressed me greatly, and it was once available on my previous site, but people, when I do get the forthcoming QB-related downloads section on the AAP Official Projects Squad, I will bring that excellent editor back. You count on it, guys! :wtnod:



Be seeing you all later, and thanks again! :king:




- Adigun Azikiwe Polack
One of the Founders of “Aura Flow”
Continuing Developer of “Frantic Journey”
Current Developer of “Star Angelic Slugger”
Webmaster of the “AAP Official Projects Squad”