 |
Castle Paradox
|
| View previous topic :: View next topic |
| Author |
Message |
PlayerOne
Joined: 07 Sep 2005
Posts: 143
Location: UK
|
 Posted: Sun Mar 19, 2006 3:09 pm Post subject: |
 |
|
| A MIDI editor would be a major project in itself. Including the link to Anvil in the readme might be an idea, though. |
|
| Back to top |
|
 |
The Drizzle
Who is the Drizzle?
Joined: 12 Nov 2003
Posts: 432
|
| Posted: Sun Mar 19, 2006 4:37 pm Post subject: |
|
|
| Quote: | | In reference to #2, the current attack bitset 'cause heroes to run from battle' does not make them run when the enemies are unescapable (the "CANNOT RUN" box appears instead). I would like a new bitset that overrides this. Or is this a bug with the current bitset? |
Oh sorry, that's not what I meant. What I meant was there should be an "esc doesn't cause heroes to run" bitset so that designers can choose to use the regular method or to make their own command for heroes to run from battle using the "force heroes to run" bitset.
_________________
My name is...
The shake-zula, the mic rulah, the old schoola, you wanna trip? I'll bring it to yah... |
|
| Back to top |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Mon Mar 20, 2006 12:41 am Post subject: |
|
|
| Mike Caron wrote: | | FyreWulff wrote: | | Sounds effects - I seem to remember TMC saying he was going to try to implement them. The memory will be available to finally play WAVs/etc |
Yes and no. Yes, it's possible, but not until we drop QB (which is looking less likely to happen soon)
|
We just need to wait until someone decides on a music library that can play all our favorite music formats (mod and it and xm and ogg), then, *ahem*copy-pasting over the Music Menu code*ahem* will be a piece of cake.
| Mike Caron wrote: |
| FyreWulff wrote: | | sizes of NPC/sprite - probably never. one, for the sake of ease of use. two, easily fakeable with plotscripting. three, backwards compatibility, and four, if you really want bigger sprites, you should also be working in a bigger resolution like 640x480, in which case you should check out engines like Game Maker |
1: Bull. 2: Bull again. 3: Bull. 4: More bull.
In short, no reason, and it will happen later. When we drop QB. |
I have to disagree there. Anyway 60x60 sprites would be way too big on a 320x200 screen. And I agree with Simon about the future of the engine. I'm even a little regretful to leave DOS behind (but no regrets about QB specifically). I'm not much in favour of huge walkabout sprites. What I WOULD like to see is the ability to draw hero/enemy/attack etc sprites to the screen with plotscripting. Don't you people realise that drawing with NPC's is unnatural? I ignore a few NPC requests because they seem to be asking for a hackish way to draw sprites out of NPCs. I hope in future that sort of thing will be easy to plotscript. I see no reason anyone would want a walkabout that large. And realise how much of the engine would need to be changed to accomodate it.
_________________
"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: Mon Mar 20, 2006 7:09 am Post subject: |
|
|
60x60 would only be too big for an RPG, which time has proved is not what idiot scripters like me use the OHRRPGCE for, rather than pure-progging it as if we were sane.
_________________
|
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Mon Mar 20, 2006 11:32 am Post subject: |
|
|
As soon as we decide that QB goes, I can add the sprite drawing stuff. I think it would be best implemented like strings. Aka, you load a sprite into a given index, and then set it to draw somewhere on the screen. Then, it does so until you move it or make it go away.
However, how, exactly, should it be set up? X number of sprites per type? X number of sprites overall, no matter what type? It would probably be easier doing the former, if we stick to fake video pages (you know we can have unlimited video pages with FB, right?). But, when we stop using the pages, the second one will probably become easier. :\
_________________
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 |
|
|
TMC
On the Verge of Insanity
Joined: 05 Apr 2003
Posts: 3240
Location: Matakana
|
| Posted: Wed Mar 22, 2006 12:28 am Post subject: |
|
|
| Moogle1 wrote: | | 60x60 would only be too big for an RPG, which time has proved is not what idiot scripters like me use the OHRRPGCE for, rather than pure-progging it as if we were sane. |
Well, that's why I suggested something better.
60x60 walkabout sprites don't even make sense without a 60x60 tilegrid, which doesn't make sense without something higher than 320x200 resolution, which requires a rewrite of all the menus and graphics in the engine.....
Definitely the second option. Would it be so hard to add in an alternative to video pages without converting everything over?
_________________
"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: Wed Mar 22, 2006 6:02 am Post subject: |
|
|
Nonsense! 60x60 sprites are perfect for, say, custom battle engines, even on a 20x20-base tilemap.
_________________
|
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Wed Mar 22, 2006 10:03 am Post subject: |
|
|
Gigantic walkabouts would be ok. Like, in Final Fantasy 6, where the Magitek Armour is 32x32 or something, and the tiles are only 16x16
_________________
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 |
|
|
Bob the Hamster
OHRRPGCE Developer
Joined: 22 Feb 2003
Posts: 2526
Location: Hamster Republic (Southern California Enclave)
|
| Posted: Wed Mar 22, 2006 12:49 pm Post subject: |
|
|
| Mike Caron wrote: | | As soon as we decide that QB goes, I can add the sprite drawing stuff. I think it would be best implemented like strings. Aka, you load a sprite into a given index, and then set it to draw somewhere on the screen. Then, it does so until you move it or make it go away. |
I have thought about this before. It would be a fantastic way to satisfy plotscripters without complicating the walkabout system at the expense of people who just use walkabouts for... you know... walkabouts.
| Mike Caron wrote: | | However, how, exactly, should it be set up? X number of sprites per type? X number of sprites overall, no matter what type? It would probably be easier doing the former, if we stick to fake video pages (you know we can have unlimited video pages with FB, right?). But, when we stop using the pages, the second one will probably become easier. :\ |
We should not use video pages. Those were a neccesity of Mode-X VGA, but we don't need to keep using them. Once we drop QuickBasic support, there is no longer any need to used fixed sized staticly-allocated buffers for anything.
FreeBasic allows us to keep an array of pointers to buffers. Each graphic will have a dynamically allocated buffer that is exactly the right size for it, plus an integer reference counter that tells how many references to it currently exist. The list of scriptable sprites will be a list of pointers to these buffers.
When you load a new scriptable sprite, it checks to see if that image has already been loaded. If so, it increments the refcount, if not, it allocates a new buffer and loads the image.
When you unload a scriptable sprite, it decrements the refcount, and if the refcount reaches zero, it unloads the sprite and frees the memory buffer.
A cool thing about this strategy is that we can backwards-compatably retrofit both the walkabouts and the battle graphics to use the exact same sprite management code, which will make it easy to do things like increasing the maximum NPC's on a map, or adding additional animation frames for enemies. |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Wed Mar 22, 2006 4:23 pm Post subject: |
|
|
I'm not sure how extensively you've looked at gfx_fb*, but that's almost how the video pages work now. Except, without the ref-counter.
Hmm... I'm not even sure we need the ref-counter at all. Here's how I envision using these sprites:
| Code: | variable(s)
load sprite(1, sprite:hero,3) #load hero #3 into slot one
place sprite(1,20,30) #draw him at (20,30)
#stuff
load sprite(1, sprite:weapon,23) #23rd weapon, overwrite the hero spriote
#etc etc |
loading a sprite just uses existing buffers.
_________________
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 |
|
|
NeoTA
Idiomatic Nomenclature
Joined: 15 Mar 2004
Posts: 165
|
| Posted: Wed Mar 22, 2006 11:12 pm Post subject: |
|
|
Mike: That comes under the 'unforeseen sideeffects' category; You cannot guarantee that a script you call will not overwrite a specific slot, so graphics may change and make things look wrong.
Management is needed for complex scripting (and desirable for simple scripting) |
|
| Back to top |
|
|
AdrianX
..yeah.
Joined: 13 Feb 2003
Posts: 286
Location: Batangas City,Philippines
|
| Posted: Thu Mar 23, 2006 5:22 am Post subject: |
|
|
..1. have a "strike without weapon" for heros under attack appearance.this could be much more effective that the "cast" attack appearance when it comes to throwing items in battle.
2. change the color of the damage in battle.
3. have something like a "reverse drop" attack behavior. |
|
| Back to top |
|
|
Battleblaze
Warrior Thread Monk
Joined: 19 Dec 2003
Posts: 782
Location: IndY OHR
|
| Posted: Thu Mar 23, 2006 6:43 am Post subject: |
|
|
I've been wanting this forever.
1)You know how wave attacks work. Just a row of the same graphic right? Well I'd really like it if wave attacks could have a "lead graphic" like for a beam attack it would have the big circle part in the front and th rest would just be the trail behind it.
2)Wave type attacks that come from the user just like a projectile attack, only in wave form. Normally when you use wave it works just like the "driveby" attack.
And as said before a standing graphic would be wonderful for walkabouts and an attack frame for enemies.
_________________
Indy OHR! and National OHR Month Contest going on now!
"Aeth calls PHC an anti-semite; PHC blames anti-semitism"
-squall |
|
| Back to top |
|
|
msw188
Joined: 02 Jul 2003
Posts: 1041
|
| Posted: Thu Mar 23, 2006 7:01 am Post subject: |
|
|
In regard to AdrianX's suggestion 1. 'strike without weapon' sounds like bug/enh #56:
"Allow individual attacks to optionally override the hero's weapon picture"
Would this enhancement accomplish what you are desiring? |
|
| Back to top |
|
|
Mike Caron
Technomancer
Joined: 26 Jul 2003
Posts: 889
Location: Why do you keep asking?
|
| Posted: Thu Mar 23, 2006 9:41 am Post subject: |
|
|
| NeoTA wrote: | Mike: That comes under the 'unforeseen sideeffects' category; You cannot guarantee that a script you call will not overwrite a specific slot, so graphics may change and make things look wrong.
Management is needed for complex scripting (and desirable for simple scripting) |
That's how many of the other features work, i.e. strings.
I think that this is better than dynamically allocating and deallocating sprites as we go along for two reasons:
1. If you accidentally not free a sprite, it'll continue to take up memory. And, making a new sprite won't free it. Then, the new sprite won't be freed, etc. This can eat up a lot of memory, and what happens when you create your 32768th sprite? IOW, it's better to leave the memory management burried in the engine.
2. It's faster and more convenient. For example, say you load up your sprites at the beginning of the game, and use them throughout.
If you accidentally overwrite a sprite because another function uses it, then you need to question why this happens, and then change one of them.
_________________
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 |
|
|
|
|
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
