 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
Newbie_Power
Joined: 04 Sep 2006
Posts: 1762
|
 Posted: Sun Feb 11, 2007 12:55 pm Post subject: |
 |
|
So why talk about it?
There was absolutely NOTHING in this thread that even talked about plotscripting and textboxes, yet you throw in this random statement that Freebasic isn't faster because it doesn't process scripting faster. Scripting doesn't even need to be faster! Script commands aren't something that happen at each cycle of game.exe.
A 32-bit programming language is faster because it takes less cycles to fill the CPU data bus, and it can handle a LOT more without choking like a QuickBasic application running in real mode would be more privy to. |
|
| Back to top |
|
 |
J.A.R.S.
In umbram deo, ex nihilo...
Joined: 11 May 2005
Posts: 451
Location: Under the rainbow...
|
| Posted: Sun Feb 11, 2007 12:57 pm Post subject: |
|
|
wow, another splendid fight raging on guys... I'll stay out of this one  Hopefully we can level down the anger over here? |
|
| Back to top |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Sun Feb 11, 2007 2:28 pm Post subject: Re: New feature |
|
|
| Mike Caron wrote: |
The only possible source of problems might be in Custom, with the wallmap issue just mentioned. I'm not exactly sure how to deal with this problem. |
My first instinct would be to AND together the bottom layer and middle layer default passability, and ignore the top layer default pasability.
Of course, maybe being able to enable/disable default passability layer-by-layer might be nice... I dunno.
| Rinku wrote: | | To answer JARS's questions, the Ohrrpgce is still coded in QuickBasic I believe; it's just a more modern version of it that supports Windows. The language itself doesn't really matter though, because the Ohrrpgce is interpreted; if it were coded in C++ it'd probably be no faster than it being coded in QuickBasic. |
Nah. We dumped QuickBasic as fast as we could after the hasta-la-qb release. :)
| Rinku wrote: | | EDIT EDIT: WOW, I think that's about as negative as we'll ever see James Paige. Any more negative and the universe would destroy itself in surprise. |
Yeah, after I posted that, John Titor appeared in a flash of light and explained to me how important it was for me to edit my post and alologize for my negativity-- for the sake of the preservation of future human society.
As for plotscripting performance, it did get a lot better when we went to FreeBasic, but that was mainly because we were able to clean up the memory management and disk-caching so nicely.
--speaking of which, TMC checked in a big optimization for scripts just a few days ago-- a change which had every bit as much potential to delay ubersetzung as Mike's layer patch did, and I didn't yell at him at all, so again, Mike, I'm sorry I snapped.
Now for the remaining problem at hand, I have John Titor sitting on my couch watching cartoon network and eating all my potato chips, and he says that if I make him leave before his "Time Window" ends in May 2011, I risk destroying causality :( |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Sun Feb 11, 2007 3:03 pm Post subject: |
|
|
| James Paige wrote: | | speaking of which, TMC checked in a big optimization for scripts just a few days ago-- a change which had every bit as much potential to delay ubersetzung as Mike's layer patch did, and I didn't yell at him at all, so again, Mike, I'm sorry I snapped. |
The difference was that I tested my changes for much of a day, while Mike suddenly appeared in #ohrdev saying "Remember layers? I'm about to check them in" "Oh nevermind, I totally broke everything. Good night." :P Actually, I was expecting someone to yell at me for overcomplication. I suppose that you were distracted by me breaking FB0.15 support for the umpteenth time.
| Rinku wrote: | | I doubt the change to FreeBasic from QuickBasic had any appreciable difference in the speed of either of those kinds of interpretation. |
Actually, I timed a maze generator someone coded in HS on the QuickBASIC and FreeBASIC builds, and it ran something like 40 times faster with FB. I don't even understand how I could have seen that improvement, but obviously it depended on the script.
| Newbie_Power wrote: | | Scripting doesn't even need to be faster! Script commands aren't something that happen at each cycle of game.exe. |
Oh, I disagree. Scripting is *still* slow, and while it takes more to bring a game to a crawl, some modest scripts eats up too much CPU time for my liking. I believe the script interpreter can still be sped up by large amounts, through optimisation. Preventing file accesses removed one bottleneck, but there are more. Anyway, I'd like to see more complicated scripts possible - there are many things that just aren't possible because they are too slow.
BTW, you're wrong about RPG files being loaded into RAM. OHR++ does that, but the loading time before the titlescreen is actually just the RPG file being unlumped.
Also, currently the OHR makes almost no use of speed optimisations provided by graphics libraries (there are several alternative ones, allegro is just one of them) - they aren't used for anything except to draw a rendered, zoomed (smoothed) rectangle to screen.
| James Paige wrote: | | Of course, maybe being able to enable/disable default passability layer-by-layer might be nice... I dunno. |
Well, we already have the "suspend default passibility" key, so it would make sense to extend it.
_________________
"It is so great it is insanely great." |
|
| Back to top |
|
|
Rinku
Joined: 02 Feb 2003
Posts: 690
|
| Posted: Sun Feb 11, 2007 4:04 pm Post subject: |
|
|
TMC basically summarized what I was going to reply with, so I'll just restate it in my own terms: the complexity possible in Ohrrpgce games is (or at least was) limited by the speed of plotscripting. It's true that most casual users won't notice this, but if you do any heavy scripting it's easy to come up against the speed ceiling.
So that's why I mentioned it, because the primary problem with the Ohrrpgce, in fact one of the reasons I moved to the Game Maker was the speed of the plotscripting interpreter. My game ZfRT couldn't really work in it, and it only did some pretty modest things by compiled standards, a few thousand lines of code executed per step, but that was too much for it, so I had to move it.
I'm happy to know that it's 40x faster now though, and yeah, I'm surprised you'd get that much of an improvement.
EDIT APPENDIX:
(19:11:22) MKiddr: speaking of which
(19:11:28) MKiddr: I found the old ZfRT demo on my hdd
(19:11:46) MKiddr: and in the new OHR the text demo actually outputs text before i'll die of old age
(19:13:17) Paul Eres: wow
_________________
Tower Defense Game |
|
| Back to top |
|
|
Newbie_Power
Joined: 04 Sep 2006
Posts: 1762
|
| Posted: Sun Feb 11, 2007 4:15 pm Post subject: |
|
|
| *humbly admits defeat* |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Sun Feb 11, 2007 4:33 pm Post subject: Re: New feature |
|
|
| James Paige wrote: | | Mike Caron wrote: |
The only possible source of problems might be in Custom, with the wallmap issue just mentioned. I'm not exactly sure how to deal with this problem. |
My first instinct would be to AND together the bottom layer and middle layer default passability, and ignore the top layer default pasability.
Of course, maybe being able to enable/disable default passability layer-by-layer might be nice... I dunno. |
Hmm, this will require thought. TMC and I were discussing this very issue on IRC the other day, the night before I checked in my patch, and I rejected that idea.
The reason is for situations like this:
Say you have a water tile. Let's also say you have a bridge tile. As it stands, placing the bridge tile on top of the water tile will cause it to replace the walls of the water tile (all solid) with those of the bridge (On the two sides, allowing passage)
But, if it were to AND the walls together, then... it works as normal. Hmm... Oh, I'm thinking of OR. I'll try this example again with a relavent scenario.
Let's say you have a grass tile. Then, let's say you also have a rock tile. The rock tile, naturally, is totally solid. You place it on your grass tile (which is all clear), and voila, you have an obstruction.
Now, if you were to AND the walls together, then the rock becomes passable, since 0000 AND 1111 = 0000.
I think the best solution is to mimic the behaviour of adding the tiles the way the user will: apply layer 0 first, then layer 1.
| James Paige wrote: | | Rinku wrote: | | To answer JARS's questions, the Ohrrpgce is still coded in QuickBasic I believe; it's just a more modern version of it that supports Windows. The language itself doesn't really matter though, because the Ohrrpgce is interpreted; if it were coded in C++ it'd probably be no faster than it being coded in QuickBasic. |
Nah. We dumped QuickBasic as fast as we could after the hasta-la-qb release.  |
I tried to dump it as fast as I could after Serendipity, but "the engine came back, the very next day! The engine came back (I thought it was a goner!)" 
| James Paige wrote: | | Rinku wrote: | | EDIT EDIT: WOW, I think that's about as negative as we'll ever see James Paige. Any more negative and the universe would destroy itself in surprise. |
Yeah, after I posted that, John Titor appeared in a flash of light and explained to me how important it was for me to edit my post and alologize for my negativity-- for the sake of the preservation of future human society. |
Bah, what do those time travellers know? I mean, clearly, human society hasn't improved much in the future if they still have spam.
| James Paige wrote: | As for plotscripting performance, it did get a lot better when we went to FreeBasic, but that was mainly because we were able to clean up the memory management and disk-caching so nicely.
--speaking of which, TMC checked in a big optimization for scripts just a few days ago-- a change which had every bit as much potential to delay ubersetzung as Mike's layer patch did, and I didn't yell at him at all, so again, Mike, I'm sorry I snapped. |
Please, I've heard a lot worse while working on this project.
| James Paige wrote: | Now for the remaining problem at hand, I have John Titor sitting on my couch watching cartoon network and eating all my potato chips, and he says that if I make him leave before his "Time Window" ends in May 2011, I risk destroying causality  |
Hmm... causality, potato chips, causality, potato chips... I, myself, would take those odds.
_________________
I stand corrected. No rivers ran blood today. At least, none that were caused by us.
Final Fantasy Q
OHR Developer BLOG
Official OHRRPGCE Wiki and FAQ |
|
| Back to top |
|
|
Ysoft_Entertainment
VB Programmer
Joined: 23 Sep 2003
Posts: 810
Location: Wherever There is a good game.
|
| Posted: Sun Feb 11, 2007 8:36 pm Post subject: |
|
|
| Newbie_Power wrote: | Rinku is all kinds of wrong.
OHRRPGCE is not interpreted. It is compiled. Before the Windows releases, it was compiled with QBasic 4.0, which allows compilation into .exe files instead of basic interpretation like the QBasic that comes with your Windows 95 CD forces.
If it were interpreted, we would be running custom.bas into qbasic.exe instead of clicking an .exe file.
And it now uses FreeBasic as its programming language. |
There is no Qbasic 4.0, the OHR was compiled in QB 4.5.
Oh, and layers is certainly a nice feature, thanks mike. Now, how about allowing the enemy, hero, and other sprites to be displayed on screen, outside of battles.
_________________
Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals.
Last edited by Ysoft_Entertainment on Sun Feb 11, 2007 8:43 pm; edited 1 time in total |
|
| Back to top |
|
|
Newbie_Power
Joined: 04 Sep 2006
Posts: 1762
|
| Posted: Sun Feb 11, 2007 8:41 pm Post subject: |
|
|
| Sorry. Un-researched error. |
|
| Back to top |
|
|
Komera
Joined: 07 Feb 2003
Posts: 711
|
| Posted: Sun Feb 11, 2007 10:20 pm Post subject: |
|
|
Okay, it's time for me to have my say:
****it! Now I have to go edit almost every tileset and map.
_________________
LJ.Art
SD - Ten creatures remaining. |
|
| Back to top |
|
|
Rinku
Joined: 02 Feb 2003
Posts: 690
|
| Posted: Sun Feb 11, 2007 10:33 pm Post subject: |
|
|
Four stars, not five?
And I actually was hoping you'd apply this to Wingedmene... I think it'd make it look nicer.
_________________
Tower Defense Game |
|
| Back to top |
|
|
Onlyoneinall
Bug finder
Joined: 16 Jul 2005
Posts: 746
|
| Posted: Sun Feb 11, 2007 11:32 pm Post subject: |
|
|
| Ysoft_Entertainment wrote: | | Newbie_Power wrote: | Rinku is all kinds of wrong.
OHRRPGCE is not interpreted. It is compiled. Before the Windows releases, it was compiled with QBasic 4.0, which allows compilation into .exe files instead of basic interpretation like the QBasic that comes with your Windows 95 CD forces.
If it were interpreted, we would be running custom.bas into qbasic.exe instead of clicking an .exe file.
And it now uses FreeBasic as its programming language. |
There is no Qbasic 4.0, the OHR was compiled in QB 4.5.
Oh, and layers is certainly a nice feature, thanks mike. Now, how about allowing the enemy, hero, and other sprites to be displayed on screen, outside of battles. |
Woah! Ysoft! I was wondering if you were still around.
_________________
http://www.castleparadox.com/gamelist-display.php?game=750 Bloodlust Demo 1.00
 |
|
| Back to top |
|
|
Ysoft_Entertainment
VB Programmer
Joined: 23 Sep 2003
Posts: 810
Location: Wherever There is a good game.
|
| Posted: Mon Feb 12, 2007 7:22 am Post subject: |
|
|
Of course I am still around. I won't retire anytime soon. I was just busy with watching animes and reading manga to post anything in here.
_________________
Try my OHR exporter/importer.
OHRGFX
Striving to become better pixel artist then Fenrir Lunaris. Unfortunately the laziness gets in the way of my goals. |
|
| Back to top |
|
|
Fenrir-Lunaris
WUT
Joined: 03 Feb 2003
Posts: 1747
|
| Posted: Wed Feb 21, 2007 8:47 pm Post subject: |
|
|
| The nightly for Feb/21/2007 seems to break the PGup/PGdown functionality in the layers. Or it's been changed. Also, I'd like to report a bug (possibly) - where placing a layered tile over an animating tile ocassionally causes all instances of the animating tile to become either the new tile, or revert to the map default tile. No idea what's going on here. |
|
| 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
