05-15-2004, 05:41 PM
So you want to make an RPG? Well, there's a lot of things you're going to need to know. You can NOT just jump right into it! Well, you can, but then you won't get past the damn map engine!
Okay, for starters, you're going to need to pick a language. Since Qbasic is one of the slowest, crappiest, oldest languages still "commonly" used, I very obviously suggest using *it*! Yep. Nothin more fun than tryin to paint a masterpeice using a fricken fork.
Okay, now we got the language out of the way. "What next, SEPH!?!!!!" you ask nervously. The libs. Yes, the libs. What lib do you use, if any? Is PureQB the way to go? Well, ask yourself this. Do you want to put yourself through hell and then some, just to say "I made a PQBRPG!!!" and get about 4 claps altogether in the Qmunity? Well if you're the nutjob who said yes, then PQB it is! For the rest of us norms, we'll try sticking with one of the less suicidal paths:
- DirectQB: old, but powerful
- M-something lib: I forgot the name, it starts with M. Basically a newer, "better" version of DQB
- Future.lib: Who needs 1024x768 res in QB!
- UGL: Great for speed, and runs efficiently and smoothly. my choice.
- Zephyr's: Never even heard of it until now.
Okay, so that's settled. Use UGL cause it's fast and furious. Why not use mode 13h you ask? Well, I never quite explained this. But many people have. Here's my perfect example: Using PSET to set a point's colour is one of QB's slowest ways of setting a point's colour. And yet, it's QB's choice for all the examples in the help menu. So, if QB's own functions are slwoer than their secondary functions, then why the hell use ANY of QB's own natural functions? Why not rely on something we KNOW is fast and works?
Okay, next section. The variables! Wait, we'll get to that in a minute. First, you're going to need more than one module (.bas file) since RPGs are usually complicated. If you're going to make a crap RPG with only one .bas file and just DATA for images, then go to hell and get out of this thread. You don't deserve to live. Anywho, Make sure you have QB 7.1 downloaded, with libs. Why not QB 4.5 you ask? Well when making my games using UGL, I could only compile a certain size game before the program simply didn't wanna compile anymore. Which reminds me, you're going to want to do all your coding in Notepad.exe, and compile out of the QB IDE. It's one hellofa lot faster and easier... if you don't think so, then keep proggin in QB's own slow IDE, but you still should compile by hand. I myself used a modified version of one of Blitz's batch files for compiling my games, since they look confusing and I didn't wanna write one of my own. So back to my point, use QB 7.1 and compile outside of the QB IDE. It produces smaller code and it compiles faster. Don't know why, just know it does. And you're going to have to link the modules together when compiling. I think this has something to do with a .mak file (just a text flatfile with a list of the .bas files in all CAPS and then a linebreak at the end).
I would go onto the variables but it's been so damn long since I coded, I forgot what the hell I'm talking about. So someone else must finish this off. NOW!
Okay, for starters, you're going to need to pick a language. Since Qbasic is one of the slowest, crappiest, oldest languages still "commonly" used, I very obviously suggest using *it*! Yep. Nothin more fun than tryin to paint a masterpeice using a fricken fork.
Okay, now we got the language out of the way. "What next, SEPH!?!!!!" you ask nervously. The libs. Yes, the libs. What lib do you use, if any? Is PureQB the way to go? Well, ask yourself this. Do you want to put yourself through hell and then some, just to say "I made a PQBRPG!!!" and get about 4 claps altogether in the Qmunity? Well if you're the nutjob who said yes, then PQB it is! For the rest of us norms, we'll try sticking with one of the less suicidal paths:
- DirectQB: old, but powerful
- M-something lib: I forgot the name, it starts with M. Basically a newer, "better" version of DQB
- Future.lib: Who needs 1024x768 res in QB!
- UGL: Great for speed, and runs efficiently and smoothly. my choice.
- Zephyr's: Never even heard of it until now.
Okay, so that's settled. Use UGL cause it's fast and furious. Why not use mode 13h you ask? Well, I never quite explained this. But many people have. Here's my perfect example: Using PSET to set a point's colour is one of QB's slowest ways of setting a point's colour. And yet, it's QB's choice for all the examples in the help menu. So, if QB's own functions are slwoer than their secondary functions, then why the hell use ANY of QB's own natural functions? Why not rely on something we KNOW is fast and works?
Okay, next section. The variables! Wait, we'll get to that in a minute. First, you're going to need more than one module (.bas file) since RPGs are usually complicated. If you're going to make a crap RPG with only one .bas file and just DATA for images, then go to hell and get out of this thread. You don't deserve to live. Anywho, Make sure you have QB 7.1 downloaded, with libs. Why not QB 4.5 you ask? Well when making my games using UGL, I could only compile a certain size game before the program simply didn't wanna compile anymore. Which reminds me, you're going to want to do all your coding in Notepad.exe, and compile out of the QB IDE. It's one hellofa lot faster and easier... if you don't think so, then keep proggin in QB's own slow IDE, but you still should compile by hand. I myself used a modified version of one of Blitz's batch files for compiling my games, since they look confusing and I didn't wanna write one of my own. So back to my point, use QB 7.1 and compile outside of the QB IDE. It produces smaller code and it compiles faster. Don't know why, just know it does. And you're going to have to link the modules together when compiling. I think this has something to do with a .mak file (just a text flatfile with a list of the .bas files in all CAPS and then a linebreak at the end).
I would go onto the variables but it's been so damn long since I coded, I forgot what the hell I'm talking about. So someone else must finish this off. NOW!
earn.
) you can't support ems by cranking up the tab. you have to go into the bios and disable the usb controller or something like that. It seemed to work for me, but it means i can't use the usb devices 
just thought you guys would like to know, and know why that idiot barok can't figure out how to enable ems. :lol: 
Ask about our hosting 
The problem is the ROM for all those onboard devices ends up where your pageframe would go...since there's no room for a pageframe, EMS no workie. I've tried disabling every onboard device, but I get the same results.