Qbasicnews.com

Dearest all of the QB45/QB71/FB community,

Hello again, and I just gotta say tonight that in going into this potentially interesting new topic pertaining to FreeBasic, there was a sprite editior that *many* of us including myself as well DO remember very fondly entitled PixelPlus 256 (or PP256) by the wonderful author Chris Chadwick, and it was EXCELLENT for making games/projects in QB and other good stuff!! ! Now, I am sure that if anybody were to make some sort of lib for FB to add or include the sprite routines that are PP256-compatible to be implemented to work for that new programming language that is currently waiting for its first public release, then that would put us over into actually enabling us to port our work from that sprite editor over to the programming in FB to inspire us more and more to create great new Windows-based games. It is kind of like what RelLib successfully did for DOS in QB, so hey, how’s that for an idea, hmm?

So, any thoughts on it, and how the possibilities of that is gonna be on this? You make the call.

Thank you all so much, and you have yourselves an excellent good night now.



THINKING SOME CREATIVE IDEAS FOR FB HERE,


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”

That won't be included with the official release (nor BLOAD and BSAVE will), but i guess it will not be too hard to code loaders for that format and put them on an include file or lib (you can have functions on a FB include file, they don't have to be only declarations as in QB).

What the format used by that editor anyway..

PP256 uses the standard BSAVE method, but it's a smart application that reads each successive graphic array manually so you can put graphic arrays of multiple sizes into the same file. Also, it uses APF files (Associated Palette File) if you change the palette in the editor. I don't remember offhand which method APF files are, looking at the size of the file will tell you though (768 bytes: one byte per entry [usually stored as a string], 775 bytes: same as before but BSAVEd, 1024 bytes: long integer array for PALETTE USING, 1031 bytes: same as before but the array was BSAVEd).

The loader would be easy enough. Although you have to include the pal file to be able to convert it fully.

why would v1c put in a loader for pp256 tiles? Not everyone's gonna be making games or be using pp256 files. Just put in bsave or an equivilant for it and we're lauging.

A BSAVE is very easy to code by yourself. There's no need to have it. In QB you had it 'cause reading byte by byte in BINARY mode was really slow, but that problem doesn't exist in FB.

Besides, the BLOAD/BSAVE file format is now obsolete as it especifies a segment/offset pair of values in the header. That has no meaning in a 32 bits platform.

To Na_th_an, Richard Eric M. Lope (Relsoft), Adosorken, and v3cz0r:

You all are pretty much onto something here. Indeed, an .APF palette file from PP256 would have to be approximately 1,024 bytes long (you are correct there, Ado! =b ), something a bit more than just your normal 256-color palette that’s composed of only 768 bytes. And technically, I believe that simply making a lib that loads and supports PP256 sprites/palettes is at least a bit better than just adding them in-house for FB (even between the two), you know what I mean?

Take a look please at the *original* PP256 palette-loading routines right here. :king:

First one — InitPaletteData:

[syntax="QBasic"]'* InitPaletteData() subroutine:
'* Initializes a long integer array with palette colour data - this must be
'* done before changing palettes with the PALETTE USING statement. The
'* calling value of FileName$ dictates whether the data should be read
'* directly from a palette file or from DATA statements (see below).
'*
'* Parameters:
'* FileName$ - The name of the palette file to load. This must include
'* the path to the file if it does not reside in the
'* current directory. If FileName$ is an empty string (""),
'* palette data is read from DATA statements.
'* PaletteArray&() - Dynamic, long integer array to hold palette data.
'*
'* Note: Before calling InitPaletteData() to initialize a palette from DATA
'* statements, use an appropriate RESTORE statement to ensure the
'* correct DATA statements are read.
'*
SUB InitPaletteData (FileName$, PaletteArray&())

'Size array to hold all 256 colours.
REDIM PaletteArray&(0 TO 255)

IF FileName$ <> "" THEN
'*** Read palette data from file ***
FileNo = FREEFILE
OPEN FileName$ FOR BINARY AS #FileNo
FOR n = 0 TO 255
GET #FileNo, , colour&
PaletteArray&(n) = colour&
NEXT n
CLOSE #FileNo
ELSE
'*** Read palette data from DATA statements ***
FOR n = 0 TO 255
READ colour&
PaletteArray&(n) = colour&
NEXT n
END IF

END SUB[/syntax]

.......and now the second, ChangePalette:

[syntax="QBasic"]'* ChangePalette() subroutine:
'* Quickly changes the current colour palette to the colours held in
'* a palette array.
'*
'* Parameters:
'* PaletteArray&() - Long integer array holding the colours to be used as
'* the new colour palette. This array must have previously
'* been initialized by calling InitPaletteData().
'*
SUB ChangePalette (PaletteArray&())

'Break down all 256 colours into their RGB values.
DIM RGBval(0 TO 255, 0 TO 2)
FOR n = 0 TO 255
c& = PaletteArray&(n)
b = c& \ 65536: c& = c& - b * 65536
g = c& \ 256: c& = c& - g * 256
r = c&
RGBval(n, 0) = r
RGBval(n, 1) = g
RGBval(n, 2) = b
NEXT n

'Write colours directly to the video card.
WAIT &H3DA, &H8, &H8: WAIT &H3DA, &H8
FOR n = 0 TO 255
OUT &H3C8, n 'Select attribute.
OUT &H3C9, RGBval(n, 0) 'Write red.
OUT &H3C9, RGBval(n, 1) 'Write green.
OUT &H3C9, RGBval(n, 2) 'Write blue.
NEXT n

END SUB[/syntax]

And apparently, the standard example usage for loading the palette (as according to the file “USERSUBS.bas” from PP256) is:

[syntax="QBasic"] 'Load standard palette.
REDIM StandardPal&(1 TO 1)
CALL InitPaletteData(Path$ + "\PALETTES\STANDARD.PAL", StandardPal&())
CALL ChangePalette(StandardPal&())[/syntax]

Also, for the sprite-loading routines, the program uses InitImageData........

[syntax="QBasic"]SUB InitImageData (FileName$, ImageArray())
'* InitImageData() subroutine:
'* Initializes an integer array with image data - this must be done before
'* displaying an image using the PUT(graphics) statement. The calling value
'* of FileName$ dictates whether the data should be read directly from an
'* image file or from DATA statements (see below).
'*
'* Parameters:
'* FileName$ - The name of the image file to load. This must include the
'* path to the file if it does not reside in the current
'* directory. If FileName$ is an empty string (""), image
'* data is read from DATA statements.
'* ImageArray() - Dynamic, integer array to hold the image data.
'*
'* Note: Before calling InitImageData() to initialize images from DATA
'* statements, use an appropriate RESTORE statement to ensure the
'* correct DATA statements are read.
'*

IF FileName$ <> "" THEN
'***** Read image data from file *****

'Establish size of integer array required.
FileNo = FREEFILE
OPEN FileName$ FOR BINARY AS #FileNo
Ints = (LOF(FileNo) - 7) \ 2
CLOSE #FileNo
REDIM ImageArray(1 TO Ints)

'Load image data directly into array memory.
DEF SEG = VARSEG(ImageArray(1))
BLOAD FileName$, 0
DEF SEG
ELSE
'***** Read image data from DATA statements *****

'Establish size of integer array required.
READ IntCount
REDIM ImageArray(1 TO IntCount)

'READ image DATA into array.
FOR N = 1 TO IntCount
READ X
ImageArray(N) = X
NEXT N
END IF


END SUB[/syntax]

.....and MakeImageIndex:

[syntax="QBasic"]SUB MakeImageIndex (ImageArray(), IndexArray())
'* MakeImageIndex() subroutine:
'* Constructs an image position index for the images held in an image array.
'*
'* Parameters:
'* ImageArray() - Dynamic, integer array holding images to be indexed.
'* IndexArray() - Dynamic, integer array to hold the index for images in
'* ImageArray().
'*

'The index will initially be built in a temporary array, allowing
'for the maximum 1000 images per file.
DIM Temp(1 TO 1000)
Ptr& = 1: IndexNo = 1: LastInt = UBOUND(ImageArray)
DO
Temp(IndexNo) = Ptr&
IndexNo = IndexNo + 1

'Evaluate descriptor of currently referenced image to
'calculate the beginning of the next image.
X& = (ImageArray(Ptr&) \ 8) * (ImageArray(Ptr& + 1)) + 4
IF X& MOD 2 THEN X& = X& + 1
Ptr& = Ptr& + (X& \ 2)
LOOP WHILE Ptr& < LastInt

LastImage = IndexNo - 1

'Copy the image index values into the actual index array.
REDIM IndexArray(1 TO LastImage)
FOR N = 1 TO LastImage
IndexArray(N) = Temp(N)
NEXT N

END SUB

[/syntax]

.....and also, if I do remember correctly, the proper loading of the sprite routines would have to be:

[syntax="QBasic"]REDIM SHARED Example(1 TO 1) AS INTEGER
REDIM SHARED Example.Id(1 TO 1) AS INTEGER
InitImageData "Sample.put", Example()
MakeImageIndex Example(), Example.Id()[/syntax]

I hope this all gets your attention right here now. !



And to Barok:

Quote:why would v1c put in a loader for pp256 tiles? Not everyone's gonna be making games or be using pp256 files.

You are probably correct, Barok. While there are some people who will be interested in trying their hand at using sprites from that classic editor to be worked on in their FB programs (should the lib for it becomes possible and available), not everybody is gonna be using it, as they might have other things to experiment or program in within FB itself. In the first place, I grant you in advance that the loader for PP256 sprite/palette conversions is a *real* challenging task to convert, especially with how the routines work, too. If you can go above within this post only, you can see all about them themselves, okay? That way, man, it will hopefully give you some ideas and things that I am gonna leave you with for this post.



I thank you all again, and I am certain that all this will get you thinking, people. ^_^ !




- 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”

The best choice is porting those PP256 routines to FB and we are done.

As it stands now, is there a standard graphic format that could be used for sprites? for Tiles too while we're at it? I know that in a 32bit world, alot of limits dissapear, but I think it might be a good idea if some form of standard (whether an existing format or a custom made one) might be a good idea. and of course good import routines for those that have exhaustive catalogs of graphics made in older programs at the time that don't want to have to redraw them ;-).

"Tiles" and "sprites" from a programming point of view are identical. There's already several "standard" formats for graphic arrays. Virtually all programmers already use one or more of them.