Qbasicnews.com

I bet Plasma didn't discover it but worked on it. The IBM PC is very well documented. SetVideoSeg just fools QB so it thinks that the video segment is somewhere else. Only that it is not in the QB help.

The dirty rectangles technique using an array of changes and GET/PUT is not in the QB help as well, but it is really useful. Is that unfair?

I can understand when people just use the QB commands for the challenge, but not using some techniques is out of my understanding. Mostly when those techniques are done using PQB.

If you have a very old and slow machine, you should work using the fastest techniques. The good thing about QB being almost 20 years old is that it has been hacked here and there and there is an almost complete understanding of how it works. We have a collection of hacks and techniques that help us making better games. The faster the better. Maybe you don't need it to show two balls in a black background, but if you can get that speed, you can use the extra time to add effects, scrolling or even sound.

I coded one of my games in SCREEN 7 and I couldn't make it work at full rate in my 233 Mhz computer. The uber optimized algorithms couldn't go faster having the weight of the megaslow QB graphics routines. When I reach to this point, I realize what I have to replace: the bottle neck. I think it is better to have a good game, not a good PQB algo. You can't play with the algo

SetVideoSeg simply changes the variable where QB stores the active video segment. Previously, this was not documented anywhere, however, the heavily-documented source has been available for anybody to use since day 1. As you can see, it does not 'randomly change bytes' and I guarantee it will not blow up your CPU.

In essence FFIX is a lot more unfair than SetVideoSeg because FFIX changes a code(INT 3dh) while SetvideoSeg just changes a variable. :*)

But remember, FFIX really isnt unfair, because it is just fixing a bug that should never have been there in the first place. I would still consider a program that uses FFIX to be PureQB.

Quote:But remember, FFIX really isnt unfair, because it is just fixing a bug that should never have been there in the first place. I would still consider a program that uses FFIX to be PureQB.

Following your line of reasoning, I would consider using SetVideoSeg as not cheating(SuperPUT would) as it's also a fix. QB's programmers could have done it when they made the compiler. But they didn't as they didn't use Fwait in place of 3dh. :*)

Exactly. FFIX is the same thing as SETVIDEOSEG: Both are patching QB in one way or another.

Spotted Cheetah...
>>That SCREEN 13 library was slow like a slug on my computer and driven my HDD mad You have to work on it more...<<

It was slow probablly because you said you were testing it on a 33 MHZ. machine, which will run slow with pratically any pure QB proggies. As for your HD going mad, you might not of had a disk cache active, that would be the only thing I could think of that would cause the HD to react like that. But you seem skilled enough with computers that you would've already known this was the problem, so I don't know.

>>First of all, as everyone said: forget that HDD thing! For loading you can use it, since then the disk cache does the dirty job (even on my old computer), but when saving it always uses the disk to not lose data.<<

Yeah, liike I mentioned in a previous post I might change this method to a PUT type method for copying the video buffer.
But like I also said, with all the machines I tried it on, the BLOAD/BSAVE method with a disk cache active was faster than using PUT.

>>On the other hand you should think about it when only loading too since PEEKing a byte from memory is always much faster than doing the same thing from a file. But for example PEEKing 8 bytes or more is slower if you get them from the file in one chunk (a$ = STRING$ (8, 0): GET #1, , a$).>>

Actually using bit logic is faster than peek!


>>There was a game here what made the SCREEN 13 thing perfectly, but a bit not "fair" since it rewrote some parts of QB: Bubble Fight. The "unfair" thing was that it found the space where QB stores the segment of the video memory (Without ASM, only PEEKs and POKEs), and changed it when it was necessary to make page flipping. It produced 15 FPS on my computer.<<

Yeah no one is going to completely agree what is fair and what is not fair. In a early post I listed a few things that I think is fair for labeling something pure QB, and SETVIDESEG seems fair to me.
Though I discovered SETVIDEOSEGMENT on my own by messing around with a program I wrote called FIP, which stood for File Info Pointer. It basically scanned memory until it found the bytes ''File_in'' or something like that, and would record the offset. Besides finding where QB stored it's graphics output address I've found various other goodies like where DEF SEG was and where to find current drive letters, files and their directories, and even the command line. Which everyone already knows anyways :)

But to get back to my lib, Cheetah, you make it sound like it's real slow which upsets me a bit, since I'd like to get a name out for it being one of the fastest pure QB libs out there. It uses alot of optimizing techniques that I think you overlooked, for instance,
in the sprite routine notice there is no LONG& integer calculations, also notice how I've took all the major calculations out of the deepest loops including DEF SEG which most routines don't do. all that together with trying to make it some what effecient too.
(I mean anyone could make it faster by unrolling loops, and converting the bytes to integers as LUTs, etc...but like I said I wanted to make the lib effecient too!)

So, anyways just check out the sprite blitting routine and try a different method of blasting the buffer if the current method isn't working well for your computer.
(You'll realize the speed my lib actually posseses :)

CYA.

What a huge mess was risen on this fair and unfair thing! But i started it, i must put
everything in order then...

There is a big problem with defining the Pure - QB thing. Programmers are so tricky that
they can cheat with almost everything...
For example if Pure QB would mean "codes without Call Absolute". Then i would write an
interrupt handler in ASM (it would be possible as i know how to write ASM), POKE it to an
empty memory location, and point a free interrupt vector to that. Bingo, and no Call
Absolute...

Then the definition of Pure QB in my opinion:
Codes without Call Absolute, but everything else is useable. The other restriction is
that the programmer must not execute data moved with any QB command (I think this last
is enough then, since then what to Call Absolute? ).

This definition makes Bubble Fight's technique legal. I only do not really liked it, and
considered it a bit unfair since it works with a little of "guessing". For example what
if an other sequence accidentally holds that four bytes too? Then bye - bye, hit
CTRLALTDEL, or Reset if it overwrites some system area...

When using "guessing" (into an unknown area like the computer's memory, not for examlpe
into the program's data files where the programmer is sure about what he or she can
except there) the programmer should call the user first so that they can prevent
failures, or fix it themselves if it occured (for example when autodetecting a sound
card it is possible that the program runs into a port what serves different purpose
freezing the computer. If it happens, and the user knows what is his or her sound - card
address, then fixing is possible if the autodetection can be cancelled). In the case of
Bubble Fight this way of fixup impossible, so if it fails on somebody's computer, then
there is no way to play with it.

FFIX, and speed - ups like that are legal as long as the code works well without them.
But these speed - ups should be cutted out for the competition. I let FFIX because it is
just a DECLARE SUB FFIX: FFIX statement pair, what can be easily cut out to test the
code's pure - QB speed. On the other hand i use fixed - point values at speed - critical
parts in my codes, so FFIX has not really got any affect on my programs' speed.

Cutting out these speed - ups are essential to this competition, since then it would be
possible that somebody just fails because he or she never heard about FFIX or something
else...

I think QB is not as slow as everybody thinks. For example my pseudo - 3D engine ran
nicely at somewhere between 14 and 20 FPS even running it with Windows playing MIDIs in
the background. This can not be called "slow" (I tried it with turning off Turbo too
when my computer ran at 11Mhz. It produced 6 to 9 FPS what is still acceptable. For
example Groov Buggies with wire - 3D ran at the same speed on a P233). If somebody finds
the things what QB can do fastly (For example the BLOAD cheat) then nobody will be able
to tell that the compiled program was created in QB (unless saying it). If the game we
are writing (in the Society which i told about before) will be finished ever, you will
see what i mentioned. Believe me, we are really working on it, but it is such a big
project that it is possible that we will only finish it in 2005. Or 2006 or later if
everything will go so bad as we currently can predict . At about three quarter of the
main technical part is ready already, so the speed is sure. But that will not only be
technique... Wait for it, we are working...

Cheetah.. About QB being slow, I agree with you, it's actually pretty fast (On todays machines that is!)

That said, it's slower then many other programming languages.

I'm half working on my RPG project at the moment, and the world map is huge, 256 areas, each area is 320x200 tiles, each tile is 64x64 pixels.

No loading time betveen areas, and I mean none.. 30-40 FPS, at all times, even with 4 animated sprites running on screen.

Only "cheat" would be SuperPut (SetVideoSeg)

(I'm not in this challenge no)


But still, you started the challenge, and you make the rules.

Here's a suggestion: Add a rule, saying that the programmer cannot use other peoples code.

And not alter or manipulate QB's code in any way, the programs should be pure QB, without any fix.

That means sluggy GET/PUT routines, slow gfx aso...

[quote="Spotted Cheetah"]For example what
if an other sequence accidentally holds that four bytes too? Then bye - bye, hit
CTRLALTDEL, or Reset if it overwrites some system area...[quote]

There is just 1 chance among 4Gb (over 4,000,000,000) that such a thing happens. And if this happens, there is even a smaller chance that this is a piece of code (the bytes translated to opcodes, taking in account the possible shifts, don't make any sense, so they won't ever belong to executing code (which is supposed to be correct 'cause it's running)). Also, this pokes in the 1st half of the QB segment, so no system area damaged.

SETVIDEOSEG is not harmful in any way.

Games using just PQB without this kind of alterations are whether slow or ugly. If you use double buffering you have to use your own PUT/GET routines, which will be slow as hell for sure. No matter how much you optimize: they will be slow as hell. 'cause QB is slow as hell. If you want to use the built-in GET/PUT routines then you won't be able to make a double buffer in SCREEN 13 thus your program will look flickery and ugly.