Qbasic Sprite Editor

[na_th_an]

The more, the merrier, they say. Anyhow, it is what you are used to. If someone is used to PP256, then your editor will be very useful for them if they want to make something in SCREEN 9. I am very used to graphic editors like Deluxe Paint 2 (I've used Dr Halo and Paintbrush or Neopaint for DOS a whole lot in my early days ).

I'd suggest you to make it more flexible so you can select screen mode at the beginning. That would be a great feature.

[Spotted Cheetah]

Download the new version

Command line added, so you can do it by calling QBPDRAW /12
(In Windows, You may create a BAT for it). You can type QBPDRAW /? to get help on command line conversion.


I tried DP2 - whoa! Good paint program... I only missed smooth modifiing of brushes, but everything other is great!

Our program is primarily not to draw but working on the palettes and converting images into QB format. But it is good for drawing too if you would like to work really precise (With mouse it is almost impossible. It always moves away a pixel just before clicking... I more like drawing small images by keyboard).

[Torahteen]

I had no idea you could Bload paint! cool! :bounce:

[wizardlife]

Deluxe Paint II

Definitely the best.

The only thing I do in PSP is cropping and rendering down other format files to the correct indexed palette. DP rocks for mode 13h.

[Spotted Cheetah]

I found DP2 very useful: now i am creating big sized graphics with it, but i still use the sprite editor. I think we will add PCX support to it, that would be good to not include a third software for conversion.

The BLOAD/BSAVE thing: it is what the sprite editor is for
I have got a 30Mhz 4.86, but QB loads the images (in 65000 byte size too!) in less than a second!

[na_th_an]

30 Mhz 80486?

I've heard of 80486SX (25 Mhz) and 80486DX (33 Mhz).

If you pay the shipping I cand send you a DX2 (66 Mhz), I have two and one of them is not used. Hey, 2X speed Does your mobo support DX2 processors?

[Spotted Cheetah]

I was surprised about that too, but the startup reports that it works exactly at 30Mhz.

66Mhz?? Everyone here would like to give me some more speed? It is not one of the most interesting things when we try to go back to the past? Sometimes i switch Turbo off, and go with just 11Mhz. The good old times, and (if speed kills) Windows (3.1) users will live forever!

To tell the truth we (my family, not the Society) have a better computer too, but i use it for more than 10 seconds only after midnight to surf on the Net (But i do not want to fill every topic with this...).


Currently we are working on better palette handling, and PCX support. And fixing a few bugs...

[na_th_an]

11 Mhz when turbo off. Then you have an overclocked 80486 SX.

[Spotted Cheetah]

Finally PCX support is ready, and some new palette functions were added too! You can download and try it from QB4All

[Spotted Cheetah]

It was me, who optimized the PCX file usage of QBPDraw. I will write here now how i did it

First of all I noticed a bug in the loader of version 1.6: it cut down the right - and the bottom line of the loaded PCX files. After fixing this i started testing the sizes of the output images with all of my programs what could create PCX files. Here are the results:

(All the files were 16 colors including the input ones, so the programs only did the coding, but changing anything on the image.)

Code:

File 1: An image converted from JPG
PictView         74813
Deluxe Paint II  76899
Display          74831
QBPDraw 1.6      75895
File 2: A drawing with large blocks of compressable data
PictView         17019
Deluxe Paint II  20174
Display          17675
QBPDraw 1.6      17144

My first idea was inserting this code in the scan line generation part:
(It makes the unused bytes similar to the last used)

Code:

IF j * 8 >= bmpsiz(0) THEN
  scl(j) = scl(j - 1)
  scl(j + sx2) = scl(j + sx2 - 1)
  scl(j + 2 * sx2) = scl(j + 2 * sx2 - 1)
  scl(j + 3 * sx2) = scl(j + 3 * sx2 - 1)
END IF

Then these values got:

Code:

File 1
QBPDraw (tweak1) 75540
File 2
QBPDraw (tweak1) 17258

In the first case the file size lowered as expected, but with the drawing it increased. This must have happened because the next line started with zero bytes and those unused ones were zeros too, but the last used bytes stood alone. This method increased that size wich resulted an one byte loss at (because sometimes single bytes can be compressed into 1 byte). To prevent this i tried this more complex code:

Code:

'Optimizing scan line for compression

unused = sx2 - INT((bmpsiz(0) + 7) / 8)
  'Unused bytes at the end of each plane
IF unused > 0 THEN
  FOR k = 0 TO 3
   IF k < 3 AND sx2 > 1 THEN
    s1 = scl(sx2 * (k + 1) - 1 - unused) 'End of used part of plane
    s2 = scl(sx2 * (k + 1) - 2 - unused)
    s3 = scl(sx2 * (k + 1)) 'Start of new plane
    s4 = scl(sx2 * (k + 1) + 1)
    IF ((s1 = s2) AND (s3 = s4)) OR ((s1 <> s2) AND (s3 <> s4)) THEN
     IF s1 < 128 + 64 THEN col = s3 ELSE col = s1
    ELSE
     IF (s1 = s2) THEN col = s1 ELSE col = s3
    END IF
   ELSE
    col = scl(sx2 * (k + 1) - 1 - unused)
   END IF
   FOR j = 1 TO unused
    scl(sx2 * (k + 1) - j) = col
   NEXT j
  NEXT k
END IF

After this tweaking these sizes were achieved:

Code:

File 1
QBPDraw (tweak2) 75369
File 2
QBPDraw (tweak2) 17139

These results were much better. But there is an other way to make the compression better: to try to similarize the halfly used bytes to the ones before them, so if succeed they can be compressed. This code was able to do that (of course with keeping tweak2):

Code:

IF j * 8 + k >= bmpsiz(0) THEN
  FOR s1 = 0 TO 3
   scl(j + sx2 * s1) = scl(j + sx2 * s1) OR (scl(j + sx2 * s1 - 1) AND l)
  NEXT s1
END IF

The results:

Code:

File 1
QBPDraw (tweak3) 75369
File 2
QBPDraw (tweak3) 16980

I was very surprised with the second value: it was smaller than all of my viewers' sizes! First i thought that i made something wrong, but not, the image was coded well.
The final results (by treating PictView's size as 100%):

Code:

File 1:
PictView         74813   100,00%
Deluxe Paint II  76899   102,79%
Display          74831   100,02%
QBPDraw 1.6      75895   101,45%
QBPDraw (tweak1) 75540   100,97%
QBPDraw (tweak2) 75369   100,74%
QBPDraw (tweak3) 75369   100,74%
File 2:
PictView         17019   100,00%
Deluxe Paint II  20174   118,54%
Display          17675   103,85%
QBPDraw 1.6      17144   100,73%
QBPDraw (tweak1) 17258   101,40%
QBPDraw (tweak2) 17139   100,71%
QBPDraw (tweak3) 16980    99,77% (!)

The compression method of tweak3 might be optimized only by finding out somehow to where those halfly filled bytes should be similarized: to the next scanline's first one or to the last one from the current scanline. I did not do that since it was very complex, and i was tired. So QBPDraw 1.7 was created with tweak3.

There were a small difference in the PCX files created by QBPDraw or Deluxe Paint II to Display or PictView: although all of them generated 4 plane PCXs, the last two did not keep the width of the scan line dividable by 2. QBPDraw could open all of the generated PCX files without any problem. Possibly this was why QBPDraw created sometimes bigger and sometimes smaller files than theirs.


Some other files tried with PictView and QBPDraw (tweak3):

Code:

PictView    QBPDraw
JPG Image      52333      52406    100,14%
JPG Image*      2578       2578    100,00%
Image**         1777       1804    101,52%
Drawing*        9021       9021    100,00%
Drawing        18228      17548     96,27%
Drawing         7259       6784     93,45%
File 1         74813      75369    100,74%
File 2         17019      16980     99,77%

*: It had a width dividable by 16 so none of the optimizations used.
**: A JPG style image with huge areas of one colored background.

As i could remember all of the files where QBPDraw created larger files than the others had sizes from k * 8 + 1 to k * 8 + 8 so PictView created odd number sized planes but QBPDraw so it had to process the unused bytes somehow what resulted larger sizes.