Subj : Door Programming ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Hi, I have some pretty neat ideas for some door programs. I program in PowerBasic 3.0. The question is this: The *only* .LIB I can find is DWDOOR. Has anyone had any luck writing doors with DWDOOR? Any tips for using DWDOOR? Perhaps there's another library out there somewhere(??). >My *best* advice to you would be to learn C. It will take you the farthest in life . I was a QBASIC programmer and made the switch to C in a few weeks many years ago, and I've had a lot easy time developing programs because of it. There are a *ton* of libs for C and most every book on game programming or whatever uses C. Pascal is also a very good language and there is also a lot of material available for programming. At one point I knew pascal pretty good too, but C was just more intuitive to me. I'm sure it's the other way around for some other people . >I believe in basic, if you were to open a dropfile and read it you'd do something like OPEN "DORINFO1.DEF" FOR INPUT (I apologize if I'm butchering this) >Your code example looks correct. This, however, brings on a question that I've always had about programming doors. Why is there such a need for .LIB files? There must be a decent way to write a door without all the glitz of some library that usually doesn't work properly. >Well, actually, using a library can either insulate you from having to write all the comm/door routines yourself if you're just starting out, OR, in some cases, it's the only way to get that functionality. Personally, I have a comm library that was written in tight assembly. I've then programmed my own "door" routines to suit my own particular needs. I'm just one of those do-it-yourself-you-learn-the-most-that-way kinda guys. BUT, I have learned a lot in the past by looking at those libraries and figuring out their techniques. If you're just starting, I would recommend getting a door library. DDPLUS for pascal, or one of the others for C. >I can answer that question. Freq DOORSOURCE and SKELETON from the address shown below. Door Source is a freeware library that kicks ass and Skeleton is plain ASCII QB source code. Compile and compare. >>There is also MAKEDOOR which uses a .obj file from RBBS to access a FOSSIL. It says it's freeware also. I use the routines that come with the X00 Fossil driver and my doors require a fossil, but non-standard IRQ's are no longer a problem. Subj : Program Size. ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ I am working on a program and I seem to have reached the limit as far as size is concerned. It compiles fine, but when I execute it, it returns an error #7 (Out of memory). I've shortened it as much as I know how (making SUB's and FUNCTION's for repetative processes, putting certain things into BI files), but I can't think of anything else. Is there a way around this? Things to try... Usually, if your program is running out of room, the problem is more with the size of the data than the code, although it could be the code. That would have to be a HUGE program, though... One way to cut down on data usage in your program(assuming you mean to compile it... I assume you do, since it is so big...) is to use the '$dynamic meta-command EVERYWHERE... This alone might not do much, but THEN what you do is take your larger arrays, hopefully not variable-length strings(if so, you can still do it, but it's harder...) and either create a data file with your data in it, or append it on to the end of your exe file. To make a data file, say you got a samp(0 to 255) as string*6, that will take 1536 bytes to store. No biggie there, but then what about your Scren(0 to 79,0 to 49) as integer... That'll take 8000 bytes to store... Anyway, you get the picture... Take all these and write them into a datafile. Just load up your program, let it initalize all the arrays, then load the inital values, after this part is where you open your datafile, write everything out, and end your program. This can be done like so: open "datafile.dat" for output as #1:close 1 open "datafile.dat" for binary as #1 for a=lbound(arry) to ubound(arry) put #1,,arry(a) next a 'repeat above 3 lines as necesary close 1 end The next step is to instead of actually init.ing your arrays, read this stuff in from the data file. This will force the data OUTSIDE your EXE, and make BC compile it a little better. Your EXE will be smaller, too. You can read in the data using the same method as above, but use GET #1,,arry(a) instead of put... If your program still doesn't compile, I don't know what to say, except you might look at the CHAIN command... I have had lots of trouble with it, though. Mainly, it just wouldn't pass variables. :) Ok, if you made it this far and the source compiles, you CAN put this all back into your EXE like this: Rewrite your loading routines (for the arrays) to read the info from the EXE instead of the datafile. Example follows... Then after you compile it, say "COPY /B + " from DOS. This will append your datafile onto the EXE. This will NOT damage your EXE, because this EXTRA stuff won't get loaded into memory like your program. Now, to read your data out of the EXE, do something like this: open ExeFile$ for binary as #1 'Exefile returns full path and 'name of the exe loaded... seek #1,EndOfExe(1) '1 says file # 1 for a=1 to lbound(arry) to ubound(arry) get #1,,arry(a) next a 'etc... close 1 Here are the ExeFile$ and EndOfExe functions... ANOTHER OPINION!!!! What is probably happening is that the program size is fine, but the program's DATA (variables, large arrays, lots of strings, etc...) is probably too large. Try shortening your arrays if you can, because those take up the most memory. Use variables that are local to SUBs/FUNCTIONs so that memory is freed when the routine exits. Put any info contained in DATA statements into a text file (or some other type of file) and then load it in to memory from disk. This may take a lot of work, so good luck! WHAT ANOTHER OPINION??? What is this file? Can you post Source? Or what? I'd suggest: 1.Getting rid of GOTOs...squish EVERYTHING into a Function or Sub, and call as needed. 2.Using '$DYNAMIC for Arrays. 3.Using "temp.dat" files for storage of DIM xyz(100,100,100), you know, the SUPER memory hoggin arrays...This might result in slower program execution... Subj : Time Slicing ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ I need some Time Slicing routines for my Door game. So you don't know what Time Slicing is? Here's an answer: Time Slicing is a way to give time to a multitasking environment while your program runs. For example, if you had a door game running from within Windows, then calling a Time Slicing routine while your program is idle (i.e. during pauses, or prompts for input) will give more processor time to the Windows environment to do other things. OKay, so here is what I need: * Time Slicing routines for Windows, DesqView, and any others you may have. * I also need routines to check to see if these environments are currently being used. Subj : Time Slicing ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ Here's what I use... First, for Windows and OS/2. These routines assume the declarations for the interrupt structures are present (QB.BI or QBX.BI), and that the QB.QLB or QBX.QLB quick library is loaded for use in the IDE, or you're linking in the QB or QBX.LIB library when compiling. For Windows, it's first necessary to retrieve the DOS version: ' Get DOS version InReg.AX = &H3306 CALL Interrupt(&H21, InReg, OutReg) DOSver = ((OutReg.BX AND 255) * 100) + (OutReg.BX \ 256) IF DOSver = 0 THEN InReg.AX = &H3000 CALL Interrupt(&H21, InReg, OutReg) DOSver = ((OutReg.AX AND 255) * 100) + (OutReg.AX \ 256) END IF This returns the version as an integer for simplicity (300 = DOS 3.00, 620 = DOS 6.20, etc.). Next, call the following function to detect Windows (If you attempt to execute this code under DOS 2.x, it will lock up): ' Check for Windows IF DOSver >= 300 THEN InReg.AX = &H160A CALL Interrupt(&H2F, InReg, OutReg) IF OutReg.AX <> 0 THEN WinMode = 0 ELSE WinMode = OutReg.CX END IF END IF The variable WinMode will be set as follows: 0 = Windows not detected 1 = Real mode detected (Win 3.0 and earlier only) 2 = Standard mode detected. (Win 3.11 and earlier only) 3 = 386 enhanced mode detected. For OS/2, check the DOS version, and if it's 20 or higher, your program is running under OS/2 2.0 or later: ' Check for OS/2 by checking if DOS ver >= 20. IsOS2 = DOSver >= 2000 The variable IsOS2 will be zero (false) if OS/2 is not detected, or -1 (true) if OS/2 is detected. You can also use the DOS version to determine the OS/2 version. I believe these are correct: OS/2 version DOS version returned 2.0 20.0 2.1 20.1 2.11 20.2 3.0 20.3 Once you have this information, giving up timeslices is a snap. Simply insert this code wherever your program awaits input: ' Give up timeslices under Windows or OS/2 IF WinMode = 3 OR IsOS2 THEN InReg.AX = &H1680 CALL Interrupt(&H2F, InReg, OutReg) END IF Now, for DESQview. You can do it with pure BASIC and interrupt calls also, but I use a free library called DVINTQB. Since it's very small, I'm sending it to you in this message, as a PostIt script -- just capture it from this message, run it in QB, and it will create the archive for you (The archive contains both the OBJ and the ASM source code). To detect DESQview, you need this declaration in your program: DECLARE FUNCTION DVGetVer% () All you have to do is call the DVGetVer% function. It will return zero if DESQview is not detected, and a non-zero value if it is detected. The OBJ also contains a few other routines, the most useful of which is a subroutine called DVPause, which you can call to give up time slices to DV. To use it, you'll need this declaration: DECLARE SUB DVPause () You can then simply CALL DVPause wherever you want to give up time slices. '>>> Page 1 of DVINTQB.LZH begins here. TYPE:BINAA TLEN:1457 DEFINT A-Z:DIM SHARED K,S,B&,Z&:V1 'Created by PostIt! 7.1 SUB V1:OPEN "O",1,"DVINTQB.LZH",4^6:Z&=1457:?STRING$(50,177); U"FIsR;&7ZRb#)%%O#/%%F%wY5E#&0i%%nsyv%gSfx1rxEr#%%(H;:f*\CB*=8Xav U"E#N&)y7Y[J6+'QsYHax#Tx]s(Ad4_G&/3TR#SaJ7,VI U"(.*Mnt<=t+ U"8f\ULE,F[\x,hVdu+I.1_:fw]bE/q/Z158>PoG=GcD$o$2xV*[F6cCLkOZTe*hi2>BUJmA=UW4]*2>O-KG6'T70uZccQq=6L+fSJbTq5]R^XaWS9+&VlOi.+PR4'VUp1v U"8,>P]G._bkRA4Nw8^S#R2S:l-:CkG<&LlRe?dP,oj\LRNX8E&0brOPY'bcNiC[L U"=l858bbt4f)&ts(=.w],?RbUvd7I01m>)%=G3-7CWG;mK^5F.]Z7;c-.r/M_:wr U"->7i>4#6p9.SZfP%%MsjVjJ6P's;2k\N9T_z;LK9b6W[H]r)N2&X,OC%w)e.8U- U"Ifjfd:.$eb16G4-Z)d:BQSO0Xolcsd#B#?U;X,x*.N$O#e/j>:+I'c:D8'(C(0) U"%(NKUUz?-ol'0b.$_/5\Bge,%S8oIm+VUbH%8=g.cT4LgSsmMzq9 U"(e-6eFV&kTFVu<;Q.^ch&*7dllehW)Y,x>]bhTXq>;;Kl_W5&Ks2?dbOA#QCB'M U"$Z:WX'Far?9U\Z-=IX^<$oNg_:F'cE(ahsp])r:*eC+q0RoWl4((=QiOaGY(uTR U"?gev-Wk&-O*+cwXW[$4W^v$+]5rfn-J^1&;Y%YJ.N]sRFu]9dj-8U\3QNVHfk-4 U"9^d:;&kj,Ysd$CuVuX_m6m$1^Q9uYA6.g\/X(FY>EWkx0Qa2LjESd5Q+*YYcF/u U"4$rO[41Jr]/3NhiIK3R;7%ZRL&%%%&'7%%*w%Y5E&.0i%n%syvg%Stgo%2cr U"%#%&-)tI;=(knrbU9AzO)+F%N6LmV99j6ps[pzJ55HL>Zi=O;QQ8=+8Psq21*=nOCi'HL0j;W)[n$5=%HB1Yc2c<([a-WaO=r585HmzE'l^$y U"%A<+yp'#pn%'%iUiDS$]VBH)VT\n<-gBv%n:O(pQ5JDG&V&D0LbO:jAby87L6(= U"BvOEUD:d#.\F..CPy$9>,SI?dw8e3gl(\SyRF;qs6<)zecDpDfN0nHoFh_.OYt? U".RZ=cpQ2,He]yj2?BP;X#x4nr$,y*x*=&\ U"M=;g_Jg7hx-=JfG'b>M>mC>lO=KqBfBLwYU92[y7a8_0L%s/xTqPrxqO%% END SUB CLOSE:IF S=48AND B&=Z&THEN?" :) Ok!"ELSE?" :( Bad! SUB U(A$):FOR A=1TO LEN(A$):C=ASC(MID$(A$,A))-37:IF C<0THEN C=91+C*32 IF K<4THEN K=C+243ELSE?#1,CHR$(C+(K MOD 3)*86);:K=K\3:B&=B&+1 S=(S+C)AND 255:NEXT:LOCATE,1:?STRING$(B&*50\Z&,219);:END SUB '>>> Page 1 of DVINTQB.LZH ends here. Last page. TCHK:48 þ