Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Starting a fighting game
posted! You just said (again!) that a new segment begins every 16 bytes. (Do you think about what you read?) Your article isn't saying that segments overlap by 16 bytes. It's the 64KB "window" that's overlapping by 16 bytes. You haven't said anything to indicate I'm not completely right. Your own arguments and the article you're misreading says the opposite. And a segment in ASM (in the context under discussion) isn't 64 KB either.

Even if you weren't misreading the article, no you wouldn't convince me of anything by simply by hitting me over the head with something you've read. (I do my own thinking.) One of the biggest mistakes you can make in life is to believe something has to be true just because it's written down. It gets even worse when you do that even though you know it's inconsistent with the facts that you're aware of.
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
whatever, man.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
WHY CAN'T WE ALL JUST... GET ALONG???
i]"I know what you're thinking. Did he fire six shots or only five? Well, to tell you the truth, in all this excitement, I've kinda lost track myself. But being as this is a .44 Magnum ... you've got to ask yourself one question: 'Do I feel lucky?' Well, do ya punk?"[/i] - Dirty Harry
Reply
Oh wow, sorry guys.

Really sorry.

But gosh but please get back to lamen terms for me.
1. How do you use Buffers in order to avoid flickering?
2. How do segments and offsets come into play and how would they be used?
3. Does it matter how things actually work as long as they do?
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
1.- Using a buffer: basicly you blit stuff to a buffer, which is a virtual screen. Then, when you're done, you copy your buffer to screen to make changes visible, usually synchronizing it with the VGA refresh (WAIT &H3DA,8: WAIT &H3DA,8,8 stuff).

A buffer is just a piece of memory. It is very handy making it just like your screen, so copy is direct. VGA mode13h screen takes 64000 contiguous bytes, so that's all what we need. The easiest way of allocating 64000 contiguous bytes in QB is DIMming an array that takes 64000 bytes. For example, an integer array of 32000 elements (each element is 2 bytes, so 32000x2=64000):

Code:
DIM MyBuffer%(31999)  ' 0 to 31999 -> 32000 elements

You have three choices to implement a double buffer:

a.- The easiest: use a lib.
b.- Use GET and PUT along with Plasma357's routines (SetVideoSeg). SetVideoSeg just changes the VGA segment (&HA000) so QB thinks VGA is where you tell him it is (i.e. your buffer) so graphic stuff will be drawn on your buffer and not on screen.
c.- The hardest: Code your own blitters that draw to a buffer instead of drawing to screen.

To copy the buffer to video memory you can do three things, again:

a.- The easiest: Use a lib.
b.- You can grab somewhere a short ASM code embedded into a SUB that copies memory. It is called MemCopy and you can get it in the ABC packets (search google with qb memory copy abc). You can use SETVIDEOSEG to draw in your buffer, and MEMCOPY to copy to the actual screen.
c.- The hardes: Make your array compatible with the GET/PUT format and use PUT to copy it to screen. This involves doing some calculations, but SETVIDEOSEG won't work straightforward (without having to play a little bit with it).

This works 'cause while you are drawing stuff it is not seen, so you can clear the buffer and put your sprites again without being noticed by the player. When you copy the buffer to screen the objects will be completely drawn.

The basic double-buffer loop can be as follows:

Code:
DO
   ' Do game (movement and stuff).
   ' Draw stuff on buffer.
   ' Wait to VGA refresh (WAIT &H3DA,8: WAIT &H3DA,8,8)
   ' Copy buffer to screen
LOOP

2.- Segments and offsets come to play when you are doing buffering or when you want to access memory directly. How do you use them? Well, usually you use them in two circumstances:

a.- Directly accessing to variables and/or arrays to BSAVE or BLOAD stuff, that case you just use VARSEG(variable%) or VARSEG(array%(0)) to know the segment and VARPTR(variable%) or VARPTR(array%(0)) to know the offset.
b.- To use with libraries/SetVideoSeg/Memcopy: Just the same. For example, SetVideoSeg needs your buffer's segment, so you can call it with VARSEG(buffer%(0)). Memcopy needs segment and offset of source and destination. To copy your buffer to screen just...

Code:
MemCopy VARSEG(buffer%(0)), VARPTR(buffer%(0)), &HA000, 0, 64000

You are giving: 1.- your buffer segment. 2.- Your buffer offset. 3.- VGA segment, 4.- VGA offset, 5.- # of bytes to copy (64000).

3.- Of course it matters. It is not a good policy to consider stuff as "black boxes" that simply "do stuff". If you understand how things work you'll be able to improve your algorithms and/or maybe change some stuff when you come to a problem.

---

PS.- I suggest you to learn basic stuff like double buffering before trying to code a fighting game... Or it will be a nightmare.
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
I wrote (but if QB's PUT works for you...well, then it works for you).

http://disc.server.com/discussion.cgi?id...rticle=290
ravelling Curmudgeon
(geocities sites require copying and pasting URLs.)
I liked spam better when it was something that came in a can.
Windows should be defenestrated.
Reply
a deep sighhh
·····································LINEAR INC·····································
Ø-----------------------------------------------------------------------O
From Problem to Solution - We take the shortest distance
Reply
PUT routine? I just got done with my sprite tutorial! YAy!!! http://www.venosoft.com/articles/sprite.html
am an asshole. Get used to it.
Reply
Quote:a deep sighhh

uh? didn't you understand my tut? Big Grin I spent 15 minutes on it !! !! !! ARRRGH!!

(runs for a tight rope)
SCUMM (the band) on Myspace!
ComputerEmuzone Games Studio
underBASIC, homegrown musicians
[img]http://www.ojodepez-fanzine.net/almacen/yoghourtslover.png[/i
Reply
Im probably a bit late, but I found the Glenn vs Na_th_an argument quite fascinating. I think that you are both trying to argue the same thing, but the way you are putting your cases forward seems to be causing the problem.

The Intel 8086 is a 16bit byte addressable machine. If it were to use 16bit memory addresses then it would have a maximum addressable memory of 64k (2^16 = 64k). So Intel came up with the idea of using 16 bit segment/offset pairs to produce a 20bit memory address (why they didnt combine them to produce a 32 bit address is beyond me). Obviously the segment and offset cannot be added conventially so they do the following, warning ascii art ahead, each block is 4 bits:

Code:
+--+--+--+--+
|  |  |  |  |   Segment
+--+--+--+--+
+
   +--+--+--+--+
   |  |  |  |  |   Offset
   +--+--+--+--+

+--+--+--+--+--+
|  |  |  |  |  |   20 bit memory address
+--+--+--+--+--+

From this you will notice that the addresses 0000:0040 and 0004:0000 are exactly the same, even though they refer to different segments. This is because segments overlap each other every 16bytes. However each segment is clearly 64k long, because it has a 16bit bytes addressable offset pointer.

As Na_th_an said, the current segment is really just a 64k window into the addressable megabyte (20 bit address, 2 ^ 20 = 1048576), you can use a 16bit value to address anywhere in the current segment. Because you have a 16bit number to specify the segment number you have 65536 segments, if you divide the addressable memory by the number of segments you get 16bytes, which is the amount of space each segment has before it must overlap with its neighbour, this in no way implies that segments are 16bytes long, if they were the 16bit offset would be slightly redundant.

Want more proof, try the following:
Code:
dim x as integer
dim i as long

for i = 0 to 65535
  def seg = &ha000
  poke 16, int(i - 32768)

  def seg = &ha001
  x = peek(0)

  print "x = "; x
next

Note that the value poked into offset 16 of segment k is exactly the same as the value peeked from offset 0 of segment k+1, but that peek and poke both allow a 16 bit offset, which is your 64bit segment length again.
esus saves.... Passes to Moses, shoots, he scores!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)