Something different from me (WARNING! IMAGE INTENSIVE)

[adosorken]

The screenshots say it all.




Raycasting: RTe
Graphics: DashX
Sound: BWSB

I've spent the last couple of days learning the RTe system, since it has no documentation and only a very poor example demo. I've thus far developed a system that's almost on par with Nebula. This is all in addition to the normal crap we got going on around here...

I've not yet added objects or enemies, and I only have a map editor which I basically threw together in VB6 in a couple of hours. Objects will be supereasy to add, but an enemy system is going to be a little work. I'm not sure just how good RTe is, but it's already showing a lot of limitations (especially with its handling of XMS). We'll see what develops.

[Zack]

And you said you didn't know anything about 3D...
Nice, except, like all other 3D games in QB...TOO BLOODY DARK!

[nebula]

Good to see somebody else starts modificating RTE!

I'm not sure just how good RTe is, but it's already showing a lot of limitations (especially with its handling of XMS).

That's right. RTE doesn't work on windows XP (NT and 2000), because of its handling of XMS. But (thanks to Plasma357) I have fixed this problem and recompiled the libraries compatible with windows XP.

Here is the link:
http://home.hetnet.nl/~nebula/articfls/rtelib.zip

Success!

[adosorken]

You should release the sourcecode for the modification...unless it's something as simple as checking for the version number (in which case, that's easy to fix). And when I was talking about the limitations of the XMS routines, I was talking about the fact that it can only allocate 2MB of XMS, when Future.Library can allocate far more. 2MB of XMS gives you a maximum of 512 sprites, which is...ok I guess, but I wish it gave you a bit more freedom to say the least. I wrote a fighting game engine awhile back which allocated 12MB of XMS using Future.Library and it worked just fine...I quickly filled all 12MB of it too. The problem with RTE I think is that it's using the quick and dirty way of using XMS (interrupts), not like Future.Library which likely does it properly (hooking into the XMM driver chain). Of course since I'm somewhat inexperienced in memory management, I could be completely wrong and just sounding like an inexperienced n00b who knows nothing. This is about the time Plasma steps in and corrects me.

[KiZ]

So what happened to your old ASCII fighting game that you were gonna release?

[relsoft]

Nek: RTE's XMS doesnt work on XP's because it uses 3.0 I think . WinXP I heard can only handle XMS 2.0. It's pretty easy to modify though.

Cool screenies!!!

[Plasma]

Hrrm, let's see...first of all, I think Angelo was on crack when he wrote RTE. It checks for XMS 3.0, but it doesn't actually use any XMS 3.0 functions. Windows NT/2K/XP only support XMS 2.0 (because XMS is limited to 16 MB).

So all you have to do is change the check for 3.0 to 2.0. (I've seen this in at least 2 other XMS libraries by different people...I don't know what they were thinking...)

Second, there is no way to access XMS using only interrupts. You have to call Int 2F/AX=4310h to get the driver entry point, which you then call directly. This is how RTE (and every other XMS lib) does it...look at the source and you'll see lots of "CALL [XMSfunc]".

About hooking into the XMS driver chain...yes, you can do it, but the only reason you'd want to is if you were writing your own XMS memory manager. For applications that just *use* XMS, you don't need to hook anything.

IIRC, the problem for allocating > 2MB XMS at a time occurs under Windows 98. To get around this, [I think] you can just allocate the amount of memory you need without checking the free amount first. To fix RTE, remove these lines:

Code:

MOV AH,8
  CALL [XMSfunc]          ; Query free XMS memory
  .IF AX < XMSneeded
    MOV AX,3              ; Error 3: Not enough free XMS memory
    RET
  .ENDIF

Or if you don't want to reassemble it, you can change all the bytes at offset 466h to offset 478h (starting with B4 08 and ending with 04 00) to NOPs (90h).

That should fix your problem, however, I don't have any computers running Windows 98 right now to test it...

[adosorken]

Sweet, I'll give that a try. I did find in the sourcecode where it checks for version 3 but since I'm not too experienced with XMS, I wasn't sure if such a change was so simple or not. I don't know if I can continue using RTE though...I'd like to use BWSB with it, and any time I get up to using 20 textures (81920 bytes), the things just starts crashing all over the place. I can cut it back a few and sometimes it will work...and sometimes not. It's so unpredictable that it makes it impossible to debug. I even set up an elaborate error trap that writes details to an external file for each major step that the program takes, and each time, the area of problem is different. Then I decided to change libraries...tried combining a very stripped-down DQB 1.71 with RTE...stripped out the BWSB and DashX code...and now, for some uberweird reason, I am getting an "out of data" error when compiling...in the same place in the IDE...and even after removing some unneeded variables before the point of error. No amount of SETMEM changes fix the problem. So...I don't know...I might just wait until we (na_th_an, aetherFox, and I) finish our new raycasting engine before I take this project on.

And yes...I still have the text fighter in the works...it's just on hiatus while I wait for Eric's revised library.

EDIT: OK...had to start, literally, from scratch...as the IDE destroyed 95% of the sourcecode (it saved up to the "Out Of Memory" error and ignored the rest, effectively destroying the entire game engine). One good thing did come of this though...I've learned that RTe can only handle 16 textures. You can allocate as many as you want but it will only recognize 16 of them. And I made the changes you suggested...time to put them to use (I reassembled the source with MASM 6.11 using ml /c rte.asm as suggested by makerte.bat.).

As for now...I decided to say screw the IDE and I'm writing the sourcecode in Notepad and compiling via a batch file. Works beautifully thus far...

[relsoft]

Nek: One word..... QB4MED. ;*)

[adosorken]

I'll try it, although I've somehow gotten quite used to notepad.

Oh and I also had to stop using BWSB...I went through hours of work last night trying to get sound back into this thing. I was able to get sound effects with DirectQB, but I couldn't add QMIDI because RTe rapes the conventional memory and wont give it back for some reason. So I tried using my MIDI Slave, which sorta worked but then I was getting weird memory allocation errors when the program would end...not to mention the fact that when the slave would start up, it'd steal focus...that's a problem for me. So I decided to do the one thing I thought I'd never do...I downloaded Lithium's DS4QB++ and configured my game engine for it. Since it requires no conventional memory nor any kind of XMS or EMS...nothing but function calls...RTe didn't complain, and now I have a fully working sound system. Which is fine with me...the size of my modules has plummetted since I don't have to store all the sound effects in EACH module (no, I'm not using MO3, it's not necessary, and it would destroy the music) and now I can use the original 16 bit samples rather than the resampled mess I had to make out of them. So with that MAJOR freeing of the memory, there's plenty of room left for...actual game code.

And now I can put DashX back into the 2lords.lib library, where it rightfully belongs.