 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
phyrfox
Avid Player
Joined: 20 Feb 2005
Posts: 96
Location: New York, USA
|
 Posted: Tue Feb 22, 2005 4:44 pm Post subject: |
 |
|
| jabbercat wrote: | | X-P 80? 120? How? Can I see your blitting code? |
Actually, the thought to keep in mind here is my system is very souped up. I don't have your run-of-the-mill system, so I always find myself scaling down to approximate what other systems would give. I'm running 1.49Ghz with 768MB of system RAM, and 128MB of video RAM (on an 8x AGP, for that matter). So it's hard to approximate how fast things will actually go on a lower system.
The current blitting code runs through a three-phrase process:
1) A 320x240 8-bit buffer is filled with pixels using a custom putpixel, writetext, and/or putimage routines (putimage not being implemented yet). Everything runs through putpixel regardless. It's a sneaky conversion that I managed to pull off, and looks like the following:
| Code: |
inline void putpixel(unsigned int x, unsigned int y, int c)
{ if(x > 319 || y > 239)
return;
SmallBuffer.pixels[y][x] = c;
}
|
Notice that I implicitly convert the pixel's point to an unsigned number, which will give me a number greater than the size of the screen if the number is negative, thus avoiding the need to test for less than zero. (saves clock cycles). Also, it's implemented inline, which saves some odd 40 clock cycles a pixel, but increases executable size.
As for the blitting, I have software filters that convert SmallBuffer to the screen->pixels buffer (640x480x32) using palCurr (the current palette, of course), blending with the options ScreenModeV and ScreenModeH (controls vertical and horizontal blending), then I use SDL_FlipSurface(screen) to actually bit to the screen.
The entire process is really simplistic and optimized with a few "interesting" loops that remind one of unrolled loops, always in the interest of gaining speed at the expense of size. Also, as much as possible, the use of ++ and -- operators (instead of +1 or -1, which might be not as optimized in some compilers). Averages are described as "X + Y >> 1", sacrificing the .5 accuracy for speed. And a "W + X + Y + Z / 4" average that is implicitly implied with a simple "X+Y/2" conversion.
-------------------------
*sigh* It's a horrible waste, because I realized that, thanks to the hardware support SDL gives, I can simply use alpha masks and a bit of trickery to produce the same results via video card... and gain even more speed.
Coding stuff that works "faster" was a major thought of mind. I always researched ways to make things faster and better. At one point I had a ASM library of common things I'd do in DOS or early Windows that were more efficient than what my peers in BASIC were doing, even if I just wrapped the stuff into a BASIC or C++ outer layer.
--------------------------
Finally, I have seen the errors of my ways. I'm going to explode all of the usable objects in memory to the proper SDL buffers, but only as necessary. Coincidently, I'm toying with two ideas: 1) keep the file open during gameplay, and read as necessary (or close/open on demand to prevent data loss, rather), or 2) loading the entire file into a buffer, and reading from that buffer. I suppose option 2 will result in less loading time, and only require about 2MB + file size instead of 2.5x times the file size.
Probably will use option 2, since memory is 100 times faster than hard drive access (although, the OS would try and optimize this by caching as much as the file as possible, this would guarantee file access in the event that you'd like to, say, share a CD with a friend with the game loaded in memory).
I appreciate all the input I've seen so far. The other place seems nearly uninterested in seeing this project, so I'll probably post more up-to-date information here.
...And though FreeBASIC is good, I don't think it's faster or more portable than a C version. It's the nature of BASIC. That's why things like VB are fast, but a Win32 C++ program is faster. So whoever does the FreeBASIC port, I'll try it out, but I plan on finishing this if it kills me.
~= phyrfox =~ |
|
| Back to top |
|
 |
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
| Posted: Tue Feb 22, 2005 7:03 pm Post subject: |
|
|
Unless you're really, really souping up the graphics capabilities, I don't see why you're worried at all about speed.
_________________
|
|
| Back to top |
|
|
phyrfox
Avid Player
Joined: 20 Feb 2005
Posts: 96
Location: New York, USA
|
| Posted: Tue Feb 22, 2005 7:56 pm Post subject: |
|
|
| Moogle1 wrote: | | Unless you're really, really souping up the graphics capabilities, I don't see why you're worried at all about speed. |
I am, actually. You'll noticed a marked upgrade in graphics, most of which will be optional commands that can be turned on and off. And eventually, if the engine is phased out to my version versus the original, there will be more features than the original could ever have due to the limitations of BASIC. |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Tue Feb 22, 2005 10:13 pm Post subject: |
|
|
I'm just concerned that alot of the new features would break some games. Eg. 320x240 or moving textboxs off screen. It would be nice if all the new features were automatically turned off when playing games created for the old version, rathering than on, in which case something which the game depended upon might have changed.
Anyway, please include some method for refreshing a map so that all npc, tilemap and passmap changes be be undone, or it will suddenly become impossible for a script to change these things freely.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
jabbercat
Composer
Joined: 04 Sep 2003
Posts: 823
Location: Oxford
|
| Posted: Wed Feb 23, 2005 2:49 am Post subject: |
|
|
| How are you controling npc's graphics and the such? Are you using surfaces? |
|
| Back to top |
|
|
phyrfox
Avid Player
Joined: 20 Feb 2005
Posts: 96
Location: New York, USA
|
| Posted: Wed Feb 23, 2005 6:00 pm Post subject: |
|
|
| jabbercat wrote: | | How are you controling npc's graphics and the such? Are you using surfaces? |
The original idea was to blit the tiles to an internal buffer, and they'd pass through the filter on their way to the screen. Now, I've decided, I'm going to just use surfaces for that feature (I'm desperately hoping SDL supports the implied 2-3000 surfaces at once). Changing resolutions will result in a recalculating of all the surfaces, they'll be "pre-filtered" instead of filtered in realtime. Should achieve much higher results that way. Additionally, looks like colored fades will require re-loading all the affected surfaces. More difficult to program, and will slow down color-change effects, but I think the change won't be too noticeable.
| The Mad Cacti wrote: |
I'm just concerned that alot of the new features would break some games. Eg. 320x240 or moving textboxs off screen. It would be nice if all the new features were automatically turned off when playing games created for the old version, rathering than on, in which case something which the game depended upon might have changed.
|
For the moment, the "default" is to have a "wide-screen" format, that is, the "tile" of pixel space above and below will be black. Optionally will be an "expanded" format, which will fill in the extra tile above and below, or the option to move textboxes to the top or bottom portion of the screen. Eventually I'll add a "permission-lock" lump. If the file does not have that lump, then they'll not be able to modify gameplay in that form (you'll have to add the lump with a password if the file is locked for editing, in order to maintain support for the password honor system). If the lump exists, it will specify features which are "forced on" by the artist, "forced off", or "user selectable". It would be encouraging to have have game developers use this function. Also by default, these things will be saved into the RPG file when edited in my version as well (when support for it is added).
| The Mad Cacti wrote: |
Anyway, please include some method for refreshing a map so that all npc, tilemap and passmap changes be be undone, or it will suddenly become impossible for a script to change these things freely.
|
Persistance will also be a feature that can be turned on under the permission-lock menu. "User selectable" will not be an option: either the developer wants this feature enabled or not. When I figure out how to expand OHR's scripting in a way that won't break the original format, there will be a "reset-map" script code as well at some point.
Although my version will be developed separately from virtually any other version, I would like to be informed of mods and updates to the code as well (I'll be rather constantly checking the official source, but unofficial mods I'd like to know about). Only features that modify the behavior of a lump or save file should be mentioned, since the rest will be basically cosmetic. Interoperability is the key focus here.
And, for whomever it was that asked... Yes. Even Macintoshs. I'll make sure I hunt you down when there's a demo version available.
Finally, there will probably be a new RPG-file format that I may be able to develop with other programmers; eventually we may be able to convert OHR into something that can evolve as needs develop.
~= phyrfox =~ |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Thu Feb 24, 2005 4:17 am Post subject: |
|
|
| Quote: | | When I figure out how to expand OHR's scripting in a way that won't break the original format, there will be a "reset-map" script code as well at some point. |
Simple. Just add new functions with ids counting down(or up) from 500 or so. Game.exe seems to completely ignore functions with ids it doesn't recognise.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
Rinku
Joined: 02 Feb 2003
Posts: 690
|
| Posted: Thu Feb 24, 2005 4:17 am Post subject: |
|
|
"if(x > 319 || y > 239) "
just curious, but the ohr has 320x200 resolution, not 320x240. what are the extra 40 lines for?
_________________
Tower Defense Game |
|
| Back to top |
|
|
Uncommon
His legend will never die
Joined: 10 Mar 2003
Posts: 2503
|
| Posted: Thu Feb 24, 2005 9:59 am Post subject: |
|
|
| Rinku, it sounds like he's going to make it 320x240. Thus the whole letterbox-style default display. |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Thu Feb 24, 2005 2:59 pm Post subject: |
|
|
Because there was no 320x200 mode available, I think. I can't think of any other reason. I think the OHR is the one with the weird resolution, because it uses mode X, which is a giant VGA hack. (However, it seems that real mode X is 320x240, but I suppose that 320x200 was used because it a standard resolution in DOS. Maybe I have it wrong. Maybe I'm blabbering on.)
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
| Posted: Thu Feb 24, 2005 3:01 pm Post subject: |
|
|
320x200 is one of the standard resolutions in QBasic and its variants.
_________________
|
|
| Back to top |
|
|
phyrfox
Avid Player
Joined: 20 Feb 2005
Posts: 96
Location: New York, USA
|
| Posted: Thu Feb 24, 2005 5:24 pm Post subject: |
|
|
Well, I can use 320x200 as well, which I will add support for, but the default 640x480 mode (which will be double-pixeled, of course) makes it an effective 320x240. That's why the extra 40 pixels. There is no guarantee I can make a 640x400 pixel mode work (except in windowed mode, of course). I decided to stick to "standard" SVGA resolution, since that will be more portable than the 320x200 (remember, that equals a 1:1.5 ratio instead of a 1:1 ratio). It'll look nicer, too. I'll experiment with the possibilities. I have to go to the airport, I'll be back to post more in a few hours.
~= phyrfox =~ |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Thu Feb 24, 2005 8:41 pm Post subject: |
|
|
| phyrfox wrote: |
For the moment, the "default" is to have a "wide-screen" format, that is, the "tile" of pixel space above and below will be black. Optionally will be an "expanded" format, which will fill in the extra tile above and below, or the option to move textboxes to the top or bottom portion of the screen. Eventually I'll add a "permission-lock" lump. If the file does not have that lump, then they'll not be able to modify gameplay in that form (you'll have to add the lump with a password if the file is locked for editing, in order to maintain support for the password honor system). If the lump exists, it will specify features which are "forced on" by the artist, "forced off", or "user selectable". It would be encouraging to have have game developers use this function. Also by default, these things will be saved into the RPG file when edited in my version as well (when support for it is added).
|
A feature-lock lump is a cool idea.
When you add a feature lock lump to a file, you could also (optionally) raise the RPG file format version in the GEN lump so that anyone attempting to run the RPG in the DOS version of GAME.EXE would get a warning that features are present in the game that it cannot support.
| The Mad Cacti wrote: | | Because there was no 320x200 mode available, I think. I can't think of any other reason. I think the OHR is the one with the weird resolution, because it uses mode X, which is a giant VGA hack. (However, it seems that real mode X is 320x240, but I suppose that 320x200 was used because it a standard resolution in DOS. Maybe I have it wrong. Maybe I'm blabbering on.) |
Yeah, most Mode-X implementations are 320x240. Mode-X is a hack, so you can't expect it to be consistent. :)
ThorBrian wrote the Mode-X assembly code, but that was so long ago, I don't recall his reasons for choosing 320x200. |
|
| Back to top |
|
|
NeoTA
Idiomatic Nomenclature
Joined: 15 Mar 2004
Posts: 165
|
| Posted: Fri Feb 25, 2005 7:34 am Post subject: |
|
|
actually, mode x is a bit more interesting than that; since it's created by setting mode 13h then tweaking the VGA registers, modes from 256 x 200 up to 400x600 are possible.
(maybe you can have it wider; i don't think you can have it taller though)
I have a prototype of a stream-based filtering system here, which i can hypothetically plug an OHR reader on the IN end*, and any number of fileformat translators on the other end listening for the kind of data they want.
Regardless of the future-format decided on, i think this architecture is nearly ideal for the kind of data translation required.
* the ohr reader isn't complete yet.
but.. * writes testcase* |
|
| Back to top |
|
|
Moogle1
Scourge of the Seas
Halloween 2006 Creativity Winner
Joined: 15 Jul 2004
Posts: 3377
Location: Seattle, WA
|
| Posted: Fri Feb 25, 2005 7:50 am Post subject: |
|
|
If memory serves, I think I found a QB hack once that let you use higher resolutions and color depths. I was really excited until I realized that I would have to write all of my own graphics functions from scratch.
Now I look back on that and laugh because in high school I thought it was the coolest thing ever to write my own C++ graphics libraries.
...Now I feel old.
_________________
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
