Pete's QBASIC Site

Btw Z!re, you can make arrays larger than 64KB in QB if you use the /AH switch. That's what it's for...it compiles using the Huge model, which allows data segments to exceed 64KB.

Well, yah:
Dim A(0 To 32767) As Double

256Kb

But then you can't do much else, can you

An entire layer for the mouse? Why not ? Umm...The mouse would natrually have its own layer otherwise it would behind or in stuff. But in order to do that without being "inefficent" Z!re's right that I have to do Z-object sorting.

But since I'm just doing the mouse I just quickly draw that mouse after everything else in real-time or if in not real-time, I'll have to have another "ghost" mouse array to hold the pixels that are behind the mouse in order to clear the mouse.

Mitth'raw'nuruodo wrote:An entire layer for the mouse? Why not ? Umm...The mouse would natrually have its own layer otherwise it would behind or in stuff. But in order to do that without being "inefficent" Z!re's right that I have to do Z-object sorting.

I can tell you're very new at this stuff. You can place anything you want at any level you want, all you do is blit in sequential order. You can attach all the fancy technique names you want to it, though. Why would it naturally have its own layer? Why would it be behind or in stuff? If you blit the mouse cursor last, you have no problem with these issues, and if you were to use the hardware mouse, you'd not even have to worry about drawing the mouse in the first place, as it would always be above everything else.

Mitth'raw'nuruodo wrote:But since I'm just doing the mouse I just quickly draw that mouse after everything else in real-time or if in not real-time, I'll have to have another "ghost" mouse array to hold the pixels that are behind the mouse in order to clear the mouse.

The "ghost" mouse array is what I explained to you. And it's perfectly fine to do it that way, in fact, it's far less wasteful to do it that way. If you were to have a seperate layer for the mouse alone, that's 64K of memory wasted when you can use less than 1K with a proper custom mouse handler. That's what I was referring to when I said that a seperate layer for just the mouse was inefficient.

Ok, got it but that's what I was saying. To draw the mouse last would be my FIRST choice. And I'm not new to this, just ASM. Oh yeah, and the mouse cusor thats already there sucks, hence my trying to make my own.

It would have its own layer (this is the way to think about it but NOT the most efficent), on the top, but since layers are just sorting then drawing according to position in the layers, you just need to draw the mouse last. AND THAT WAS MY POINT.

If the mouse wasn't on its own layer it would be on another one's layer or under another one's layer. That's why it would be behind or in it (again this is the way to think about it but not "do").

Here's how I always do it:

[Pseudo_Code]
Do
Update everything, move stuff etc

Draw background, whatever it may be: Water, space, whatever

Sort all objects, this includes: Trees, spaceships, houses, characters, bananas, and bulles.

Draw them in order, the ones furthest away you draw first.

Draw any menu, or health meter, or any other GUI you have

Draw the mouse cursor
Loop Until Exit
[/Pseudo_Code]


Ofcourse you can refine it using clipping, only updating whats needed, only draw whats needed etc etc etc etc etc...

Z!re yep but you forgot the checking of events in there, as well as a pause for us to see the output.

Uhm?

What?

Update everything, move stuff etc

That is the events.

And pause?, what?

Wait I'm sorry I didn't see that.

Pause = a little wait statement so everything that you draw doesn't get erased before your brain can analize that.

Like Wait &H3DA, 8 or a for:next or a time statement.