QuestKit, (features. pure QB, pixel X pixel scrolling)!

[Nemesis]

Well, here is one of the projects I've been working on...

http://www.petesqbsite.com/downloads/QuestKit.zip

The meat of the engine is done, (ENG.BAS), now I need to code a decent GUI, and I still have more content and features to add.
You can mess around with the engine, doing neat stuff like changing camera size, map size, tile size, and other junk.
Just look in the source, in the main sub, at...
::: User-Defined Variables ::: (These variables control the engine
Anyways, let me know what you think, some ideas, suggestions, or errors you might have/encounter.

Thanx,

Nemesis

P.S...

This is the first BETA release

[na_th_an]

just one thing:

if you are gonna use the engine in a project, if you substitute all those variables for constants which are powers of two the engine will be a lot faster.

[VonGodric]

That's cool man, keep up good work!

[Nemesis]

just one thing:

if you are gonna use the engine in a project, if you substitute all those variables for constants which are powers of two the engine will be a lot faster.

Yeah, constants are faster, but I seriously doubt you'd see an
improvement in speed. Basically, those variables are just hanging around for now, kinda unorganized, and a few might be calculated wrong. All that mess will be cleaned up, once I start the GUI, and then I can start weeding out which ones I need and don't.
Anyways, I re-uploaded the engine since I discovered a few bugs, and I needed to improve the sprite/tile collision process.
Now, I think people should get an idea how the collision detection
works, (I drew a little diagram to explain which variables are user-defined, so anyone could change the collision cordinates easily if they wanted to.)

Well, that's about it for now, check out the latest upload.

Cya!

[ThaMariuZ]

hey.. ESCorp!!! Kyper (Marc Grenham) has been working on that one. i've also been ESCorp member. That was the engine he wanted to use for his RPG project Dark Fantasy...

great, that you guys are still working on this one, but i don't see any changes (besides the graphics) from the last version i've got on my computer.

cheers

[na_th_an]

It's not only that constants is faster, it is only that the less general your program is, the more you can optimize. For example, assuming that tiles are 16x16, for example, can speed up things dramatically. For example you can substitute a lot of MODs for ANDs, plus the compiler substitutes multiplications and divisions by (a lot faster) shifts if the 2nd operand is a power of two.

But that was just a comment. You made a great work.

[relsoft]

I'd do what Nath says and if your tiles are fixed(16*16), you can unroll the inner loops for an even greater speed.

[Nemesis]

It's not only that constants is faster, it is only that the less general your program is, the more you can optimize. For example, assuming that tiles are 16x16, for example, can speed up things dramatically. For example you can substitute a lot of MODs for ANDs, plus the compiler substitutes multiplications and divisions by (a lot faster) shifts if the 2nd operand is a power of two.

But that was just a comment. You made a great work.

Umm, that's the whole point in making an RPG-maker, or RPG-kit,
it's going to be general, and as dynamic as possible. Although I'm
not sure if we both are using "general" in the same context.
I'm not trying to sound cocky or anything, but to tell you the truth,
I really don't need to worry about speed. The engine runs very fast already, actually, I need to implement a set frame rate routine to keep it running smooth and at a constant speed  :wink:
I think, 32 FPS, would be a good rate, but since it's an RPG-KIT,
(one of these days ):cry:  the set FPS will be left up to the user.
And plus there's still tons of stuff I could do, even with pure QB, that can increase the speed, without sacraficing the engines flexability. Heh, just this moment I thought about the different types of scrolling I want to include in the engine, so I simply tried changine the PLR.pace variable from 1 to 16, and what do you know, the engine scrolled just like an old tileXtile scroller.
Plus I messed around with the ENG.TILESxx and ENG.TILESyy variables and those worked pretty well if you want to change the size of the display, (although you can find some errors if you change these variables to extreme measures). I should have these minor inperfections worked out soon, once I start coding the gui, and the map-editor, maybe tile and font editor too, the engine should start coming together nicely.
But thanx for checking it out.

Rel... No, the tiles aren't fixed at 16X16, you can use a multitude of different sized tiles, sprites, fonts, maps, whatever. You can even use odd sizes. Now, I did a little-bit of testing with the engine, like I loaded different sized maps, tiles, and as I mentioned in the last paragraph, I modified some of the user-defined variables that are
currently availabe in the engine. And for the most part, it all works
pretty well, I'm sure you'll run into some trouble if you get crazy,
like trying to load 600X600 tiles, and use maps 2X2 tiles in size.
These things won't be a problem though once the gui is running, cause I can set the limits of the engine there

Well, thanx again for checking it out, I'm always open for suggestions, praise, productive critisism, etc...

Cya.