Qbasicnews.com
October 22, 2019, 03:00:47 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: Back to Qbasicnews.com | QB Online Help | FAQ | Chat | All Basic Code | QB Knowledge Base
 
   Home   Help Search Login Register  
Pages: 1 ... 5 6 [7] 8 9 10
  Print  
Author Topic: 100% QB game  (Read 44081 times)
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #90 on: August 02, 2004, 04:21:07 PM »

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 Wink
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Plasma
Na_th_an
*****
Posts: 1770


WWW
« Reply #91 on: August 02, 2004, 10:02:13 PM »

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.
Logged
relsoft
*/-\*
*****
Posts: 3927



WWW
« Reply #92 on: August 03, 2004, 01:00:23 AM »

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

y smiley is 24 bit.


Genso's Junkyard:
http://rel.betterwebber.com/
KiZ
__/--\__
*****
Posts: 2879


WWW
« Reply #93 on: August 03, 2004, 07:33:57 AM »

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.
Logged
relsoft
*/-\*
*****
Posts: 3927



WWW
« Reply #94 on: August 03, 2004, 11:24:44 PM »

Quote from: "dark_prevail"
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. :*)
Logged

y smiley is 24 bit.


Genso's Junkyard:
http://rel.betterwebber.com/
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #95 on: August 04, 2004, 08:57:06 AM »

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

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Nemesis
Forum Regular
**
Posts: 118



« Reply #96 on: August 04, 2004, 11:44:27 AM »

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.
Logged
Spotted Cheetah
Ancient QBer
****
Posts: 400



WWW
« Reply #97 on: August 04, 2004, 01:09:02 PM »

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? Smiley ).

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 Sad. 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...
Logged

fter 60 million years a civilization will search for a meteorite destroying most of the living creatures around this age...

There must be a better future for the Cheetahs!

http://rcs.fateback.com/
Z!re
*/-\*
*****
Posts: 4599


« Reply #98 on: August 04, 2004, 02:22:47 PM »

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...
Logged
na_th_an
*/-\*
*****
Posts: 8244



WWW
« Reply #99 on: August 04, 2004, 05:01:00 PM »

Quote from: "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.
Logged

SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Z!re
*/-\*
*****
Posts: 4599


« Reply #100 on: August 04, 2004, 05:57:04 PM »

Nath, doesent the windows DOS VM protect the memory?

So, for example, you can't trash other programs etc from inside a QB program using POKE...


Or is it just me living in my own happy, perfect, world of no bugs/errors :roll:
Logged
relsoft
*/-\*
*****
Posts: 3927



WWW
« Reply #101 on: August 05, 2004, 01:52:00 AM »

Spotted Chetaah:

Want me to make Bubble fight run on the same system at 40 FPS w/o SetVidoSeg and no ASM?  I can do it if you want. :*)

1.  The collision detection could be made a lil simpler and faster by not using SQR
2.  I could use the "dirty rectangle animation" Nath was taking about.
3.  And the biggest bottleneck? It uses the FPU.  I could convert all the vector stuff in Fixpoint math and it would run wild on the same system. :*)
Logged

y smiley is 24 bit.


Genso's Junkyard:
http://rel.betterwebber.com/
Spotted Cheetah
Ancient QBer
****
Posts: 400



WWW
« Reply #102 on: August 05, 2004, 01:08:41 PM »

Nemesis:

I did not want to exasperate you, but when somebody downloads something "fast", then he
not except that fastness to be 2 - 4 FPS with hearing annoying HDD sounds from under the
table all the time. Especially when this person had already tried many things to achieve
the same.

I will remake that then. The way i worked was to create a GET / PUT buffer, and alter
that as fast as possible. As i can remember i got something around 5FPS with that code
modifiing all pixels of the screen.

At the optimization side i had tried more things than what you can imagine Smiley
For example it appeared me that constant * variable is at about 1.1 times faster than
variable * constant. Would you ever try that if i do not tell? Of course i not only make
such silly things, i always look around in everything.


I now remade that way of PSETting, and i got 5.6 FPS with it. Here is the code:
(I woke up at four o'clock in the morning as i could not sleep, so do not ask what was
in me when i had written this code Smiley )

Code:

DEFINT A-Z


'$DYNAMIC
DIM scrArr%(-2 TO 31999)
'$STATIC
DIM SHARED xArr%(319)
DIM SHARED yArr%(199)
DIM SHARED m256Arr%(255)

FOR i% = 0 TO 319: xArr%(i%) = i% \ 2: NEXT i%
FOR i% = 0 TO 199: yArr%(i%) = i% * 160: NEXT i%
FOR i% = 0 TO 127
 m256Arr%(i%) = i% * 256
 m256Arr%(i% + 128) = (i% - 128) * 256
NEXT i%


SCREEN 13


FOR j% = 0 TO 319
 FOR k% = 0 TO 199
  arr% = xArr%(j%) + yArr%(k%)
  IF 1 AND j% THEN
   scrArr%(arr%) = &HFF AND scrArr%(arr%) OR m256Arr%(&HFF AND j% AND k%)
  ELSE
   scrArr%(arr%) = &HFF00 AND scrArr%(arr%) OR (&HFF AND j% AND k%)
  END IF
 NEXT k%
NEXT j%
PUT (0, 0), scrArr%(-2), PSET



(Usual PSET runs at 1.7 FPS, POKEing at 2.5 FPS on my computer)

It will be very - very slow in the IDE, but works compiled. I left the two FORs in their
usual form to test it like real PSETting where we tell the routines X, Y and Color (I
made a sub - calling form where you can call a sub with X and Y and Color, but it
produced only 2FPS. It is better to include the code as PSETting).

It is the slowest way to put pixels. Horizontal lines would be much faster (after
reworking the code of course), and putting object won't be slow too if it is enough for
the programmer to use only every second pixel of X as start point. Not to mention that
this way is 100% filcker - free.




I do not like that HDD stuff too because i think it is not really good to that poor HDD
to work all the time. Remember that it is mechanic so it has not got unlimited lifetime.
When writing data it has to move it's heads all the time what may shorten it's life. The
best is to use the memory as long as it can be used, and only start 'annoying' that HDD
when it is full so the data can not be written anywhere else. And not to mention that
you not only drive the HDD mad but the user too who have to listen it all the time (and
possibly exits to Windows, and tries to find "what the hell is working in the
background again", but nothing does).



(Sorry for these late replies and that it looks like i am not reading the topic, just
throwing things on it, but i have no time. When i go online, i always download the topic,
and post the reply to the state i downloaded at last time Sad )
Logged

fter 60 million years a civilization will search for a meteorite destroying most of the living creatures around this age...

There must be a better future for the Cheetahs!

http://rcs.fateback.com/
Nemesis
Forum Regular
**
Posts: 118



« Reply #103 on: August 05, 2004, 03:53:41 PM »

Cheetah the code you posted gave me errors, but to me it
looks like you were simply manipulating words in the buffers
array which isn't going to be much faster, if even faster, than
just using good ole POKE/PEEK.
Now you keep talking about my code driving your HD crazy
but I already mentioned to you about using a cache.
When a cache is active you HD doesn't need to access
it's hardware every frame, instead it uses cached RAM
so you shouldn't have those problems when one is present.
Since your using such old hardware this might be your main
problem when running my code. I think it's time you did a little,
umm, upgrading there guy!
Anyways you still ramble about how you got this fast, optimized
QB code but I still haven't seen it. (Not being rude, just stating the facts.)
But to give you a better understanding of the kind of optimations
I made when I coded my library I decided to post this little demonstration...

Code:

DEFINT A-Z
SCREEN 13
DO: LOOP UNTIL TIMER <> TIMER: t! = TIMER
DEF SEG = &HA000
FOR c = 0 TO 255
 FOR y = 0 TO 199
  FOR x = 0 TO 319
   POKE 320& * y + x, c
  NEXT
 NEXT
NEXT
LOCATE 1, 1: PRINT TIMER - t!
SLEEP
'
DO: LOOP UNTIL TIMER <> TIMER: t! = TIMER
FOR c = 0 TO 255
 FOR y = 0 TO 199
  DEF SEG = &HA000 + (y * 20)
  FOR x = 0 TO 319
   POKE x, c
  NEXT
 NEXT
NEXT
LOCATE 1, 1: PRINT TIMER - t!
SLEEP
'
SYSTEM
'


This snippet above shows an optimization technique I used in my pure QB lib that elliminates the LONG& calculations when accessing the screen buffer. (Although the snippet doesn't use a screen buffer, but it's all the same type of blitting technique.)
When compiled it shows some dramatic speed increases!
Now I'm not acting like I invented the wheel here, or expecting to win a nobel prize, but it's just one of the ways I discovered how to squeeze just a little more speed outa poor QB.

Cya.
Logged
Z!re
*/-\*
*****
Posts: 4599


« Reply #104 on: August 05, 2004, 05:02:27 PM »

Nemesis, your code doesent make my HD go mad, but it's still slow.

I tried it on an older computer (In a library, a 133MHz 16MB RAM, and 5400RPM 3GB Disk)

It went nuts... Constant HD reading.


But the weird part is, it was almost as fast as on this computer, where it did use buffering.


And it's always a bad habit to use the disk as a buffer, even if it's fast. for reasons Cheetah already said, it shortens it's life to be read from and too all the time.

Even if it uses the buffer, it still has to read it every time it's changed, and write it too.

The buffer doesent help much there.
Logged
Pages: 1 ... 5 6 [7] 8 9 10
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!