Re: [Ohrrpgce] Plan for bigger walkabouts
On Wed, Oct 28, 2009 at 11:59, James Paige b...@hamsterrepublic.com wrote: After Lucier posted this mockup: http://i658.photobucket.com/albums/uu304/rlb1626/genesis0055.png I wrote this plan: http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_bigger_walkabouts And when I thought about it, it sounds super-easy. Like I am talking less than a weekends' worth of work with no obvious technical hurdles. I thought I would reproduce the plan here for quick discussion: Right now, walkabout sprites are limited to 20x20. What if we simply added a new sprite type? .PT9 big walkabouts 32 x 40 x 12 640 x 12 = 7680 The size would be the same as hero graphics (for the benefit of people who want to synch battle/walkabout graphics FF6-style). There would be 3 frames in each direction. Or alternatively we might go with .PT9 big walkabouts 40 x 40 x 12 800 x 12 = 9600 Which could still be used the same way, but would allow for squarish boss npcs with only minor pixel wasteage. In the NPC editor, and the hero editor we would add an additional data element for walkabout sprite size 0=small, 1=large. (this would work just like the sprite size setting for enemies) Big NPCs would be drawn on the map with their bottom center in the same place as the bottom-center of small NPCs. There would be no special passability considerations for big walkabout sprites, they would still use 20x20 passability squares. (any change to that behavior would belong in Plan for non-tile-based walking) Ideally we want some future version to allow total flexability in sprite sizes, but this plan would be super-easy to implement, and would only add a very small additional backcompat burden (no worse than what already exists for enemy graphics) --- James insert request for sprites of a user-defined size like 20×40 or 40×20 *hope, hope* :D ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] [Bug 672] In editor context help?
http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=672 --- Comment #6 from Bob the Hamster b...@hamsterrepublic.com 2009-10-30 08:26:12 PDT --- (In reply to comment #4) If I have some additions/corrections, should I just email you the updated ohrhelp folder? Sure. just zip it up and mail it to me or attach it to this bug. -- Configure bugmail: http://rpg.hamsterrepublic.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
On Fri, Oct 30, 2009 at 08:20:11AM -0500, Kizul Emeraldfire wrote: On Wed, Oct 28, 2009 at 11:59, James Paige b...@hamsterrepublic.com wrote: After Lucier posted this mockup: http://i658.photobucket.com/albums/uu304/rlb1626/genesis0055.png I wrote this plan: http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_bigger_walkabouts And when I thought about it, it sounds super-easy. Like I am talking less than a weekends' worth of work with no obvious technical hurdles. I thought I would reproduce the plan here for quick discussion: Right now, walkabout sprites are limited to 20x20. What if we simply added a new sprite type? .PT9 big walkabouts 32 x 40 x 12 640 x 12 = 7680 The size would be the same as hero graphics (for the benefit of people who want to synch battle/walkabout graphics FF6-style). There would be 3 frames in each direction. Or alternatively we might go with .PT9 big walkabouts 40 x 40 x 12 800 x 12 = 9600 Which could still be used the same way, but would allow for squarish boss npcs with only minor pixel wasteage. In the NPC editor, and the hero editor we would add an additional data element for walkabout sprite size 0=small, 1=large. (this would work just like the sprite size setting for enemies) Big NPCs would be drawn on the map with their bottom center in the same place as the bottom-center of small NPCs. There would be no special passability considerations for big walkabout sprites, they would still use 20x20 passability squares. (any change to that behavior would belong in Plan for non-tile-based walking) Ideally we want some future version to allow total flexability in sprite sizes, but this plan would be super-easy to implement, and would only add a very small additional backcompat burden (no worse than what already exists for enemy graphics) --- James insert request for sprites of a user-defined size like 20 *40 or 40 *20 *hope, hope* :D That is something we want to allow in the future, but this plan seemed quick and easy, whereas user-defined sizes is harder, and will take more time to get right. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3022 convert itemstr GOSUB into items_menu_itemstr() SUB
james 2009-10-30 10:14:08 -0700 (Fri, 30 Oct 2009) 94 convert itemstr GOSUB into items_menu_itemstr() SUB Also renamed items() SUB to items_menu() --- U wip/game.bas U wip/game_udts.bi U wip/menustuf.bas U wip/menustuf.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: teeemcee/3023 No need to use stdcall under windows.
teeemcee 2009-10-30 10:44:53 -0700 (Fri, 30 Oct 2009) 37 No need to use stdcall under windows. --- U wip/gfx.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SDL_mixer
I noticed that the official SDL_mixer prebuilt dll's for Windows were re-uploaded on 2009-10-26. I think they may have fixed whatever was completely broken about them before (but I don't have a Windows box free to test this theory right now) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SDL_mixer
2009/10/31 James Paige b...@hamsterrepublic.com: I noticed that the official SDL_mixer prebuilt dll's for Windows were re-uploaded on 2009-10-26. I think they may have fixed whatever was completely broken about them before (but I don't have a Windows box free to test this theory right now) --- James Indeed, everything works now (except I did not test MP3). ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3024 Convert autosort GOSUB block into items_menu_autosort() SUB
james 2009-10-30 11:12:11 -0700 (Fri, 30 Oct 2009) 60 Convert autosort GOSUB block into items_menu_autosort() SUB --- U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
On Fri, Oct 30, 2009 at 03:59:59PM -0500, Kizul Emeraldfire wrote: On Fri, Oct 30, 2009 at 10:31, James Paige b...@hamsterrepublic.com That is something we want to allow in the future, but this plan seemed quick and easy, whereas user-defined sizes is harder, and will take more time to get right. --- James Ahh, I see. Hrm. Well, I WAS going to ask if it be too hard to implement 20x30 as an additional (non-user-defined) size (like old NES/SNES games with big sprites, it'd be one-and-a-half tiles tall instead of just one, or two full ones * I think Dragon Quest VI (for the Super Famicom), among other games, uses sprites of similar ratios for the main heroes and NPCs), but then I got to thinking about it and, since they'd be one-and-a-half tiles tall, moving in one-tile steps would be a tad strange; they probably wouldn't mesh up with the walls right in areas. Well, with 32x40 you could just draw your sprites at 20x30. Nothing would force you to use the extra pixels around the edge. And walls would not matter. For this plan, all NPCs would still act like they were 20x20 for purposes of walls and movement regardless of what their actual size is. So, instead: when you guys DO get around to implementing arbitrary, user-defined sprite-sizes, any chance of an arbitrary, user-defined 'step' (defined in pixels; defaulted to '20') as well? :) On the wiki there is a Plan for non tile-based walking that covers that. Also the idea of tilemap sizes other than 20x20 is not crazy (although it is still very far in the future) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3025 split off some of the item-using code in the item menu
james 2009-10-30 14:26:12 -0700 (Fri, 30 Oct 2009) 175 split off some of the item-using code in the item menu into use_item_in_slot() sub. This code is still all tangled up with the item menu. untangling it is an ongoing process. --- U wip/game_udts.bi U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
It occurs to me that custom sized tile sets (and thus, maps) are not that far away. What needs to be done: - The tile map format needs to be overhauled, so that each tile is expanded to 16 bits, so we have enough room for tile sets with more tiles. - All the places where the current tile size is used need to be replaced with variables. This is likely the most time consuming part. - This includes the various editors - Tile animation will also require upgrading, since it relies on details of current tile set sizes. This is probably the most difficult part. Of course, I'm sure you already have a Plan for all this... --Original Message-- From: James Paige Sender: ohrrpgce-boun...@lists.motherhamster.org To: ohrrpgce@lists.motherhamster.org ReplyTo: ohrrpgce@lists.motherhamster.org Subject: Re: [Ohrrpgce] Plan for bigger walkabouts Sent: Oct 30, 2009 5:12 PM On Fri, Oct 30, 2009 at 03:59:59PM -0500, Kizul Emeraldfire wrote: On Fri, Oct 30, 2009 at 10:31, James Paige b...@hamsterrepublic.com That is something we want to allow in the future, but this plan seemed quick and easy, whereas user-defined sizes is harder, and will take more time to get right. --- James Ahh, I see. Hrm. Well, I WAS going to ask if it be too hard to implement 20x30 as an additional (non-user-defined) size (like old NES/SNES games with big sprites, it'd be one-and-a-half tiles tall instead of just one, or two full ones * I think Dragon Quest VI (for the Super Famicom), among other games, uses sprites of similar ratios for the main heroes and NPCs), but then I got to thinking about it and, since they'd be one-and-a-half tiles tall, moving in one-tile steps would be a tad strange; they probably wouldn't mesh up with the walls right in areas. Well, with 32x40 you could just draw your sprites at 20x30. Nothing would force you to use the extra pixels around the edge. And walls would not matter. For this plan, all NPCs would still act like they were 20x20 for purposes of walls and movement regardless of what their actual size is. So, instead: when you guys DO get around to implementing arbitrary, user-defined sprite-sizes, any chance of an arbitrary, user-defined 'step' (defined in pixels; defaulted to '20') as well? :) On the wiki there is a Plan for non tile-based walking that covers that. Also the idea of tilemap sizes other than 20x20 is not crazy (although it is still very far in the future) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org -- Mike Caron ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
Well, with 32x40 you could just draw your sprites at 20x30. Nothing would force you to use the extra pixels around the edge. And walls would not matter. For this plan, all NPCs would still act like they were 20x20 for purposes of walls and movement regardless of what their actual size is. What if we want bigger for certain applications, such as magi-tek armor or monsters on the map? _ New Windows 7: Find the right PC for you. Learn more. http://www.microsoft.com/windows/pc-scout/default.aspx?CBID=wlocid=PID24727::T:WLMTAGL:ON:WL:en-US:WWL_WIN_pcscout:102009___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
On Fri, Oct 30, 2009 at 09:57:38PM +, dan155...@msn.com wrote: Well, with 32x40 you could just draw your sprites at 20x30. Nothing would force you to use the extra pixels around the edge. And walls would not matter. For this plan, all NPCs would still act like they were 20x20 for purposes of walls and movement regardless of what their actual size is. What if we want bigger for certain applications, such as magi-tek armor or monsters on the map? That is why I was thinking 40x40 might be a better size than 32x40. Obviously the best possible size would be Anything x Anything. My idea is centering around the theory that it might be easier to pick a good large walkabout size and implement it without waiting around for the extra work required to make Anything x Anything sprites possible. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: pkmnfrk/3026 New information! Now, ALL RELOAD nodes can bear children, even if they c
pkmnfrk 2009-10-30 17:00:44 -0700 (Fri, 30 Oct 2009) 368 New information! Now, ALL RELOAD nodes can bear children, even if they contain a value of their own! This is less useful than it sounds, but it was easy enough to do. The rough equivalent of this would be the following XML markup: foo text children.../children /foo This reduces the memory footprint a bit, but increases the disk space usage by a bit. --- U wip/reload.bas U wip/reload.bi U wip/reloadtest.bas U wip/xml2reload.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3027 Re-wrote the inventory menu to split apart the entangled code
james 2009-10-30 18:18:37 -0700 (Fri, 30 Oct 2009) 702 Re-wrote the inventory menu to split apart the entangled code for the main inventory menu, and the hero target picker. Some cosmetic changes to the picker have been made: * For cure items, shows the name of your HP or MP stat * For stat bonus items, shows the name of the stat * For teaching items, shows the hero names instead of showing HP * The name and count of the item you are using is shown right below the picker, instead of replacing the item description. * Remembers the last hero you targetted. (and updates the target intelligently if the targeting rules are different for the next attack) I have tested the heck out of this, but please everybody test some more heck out of it. --- U wip/game_udts.bi U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3028 Minor cleanup to use_item_in_slot()
james 2009-10-30 18:36:14 -0700 (Fri, 30 Oct 2009) 36 Minor cleanup to use_item_in_slot() --- U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3029 items_menu() SUB no longer depends on REMEMBERSTATE/RETRIEVESTATE
james 2009-10-30 18:50:46 -0700 (Fri, 30 Oct 2009) 66 items_menu() SUB no longer depends on REMEMBERSTATE/RETRIEVESTATE --- U wip/game_udts.bi U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3030 Remove the unused atktemp() buffer from use_item_in_slot()
james 2009-10-30 18:59:32 -0700 (Fri, 30 Oct 2009) 134 Remove the unused atktemp() buffer from use_item_in_slot() And replace the atktemp() buffer in chkOOBcure() with an AttackData object --- U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3031 convert oobcure() to use AttackData instead of a buffer
james 2009-10-30 19:22:22 -0700 (Fri, 30 Oct 2009) 56 convert oobcure() to use AttackData instead of a buffer --- U wip/menustuf.bas ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] SVN: james/3032 Convert itcontrol GOSUB block into items_menu_control() SUB
james 2009-10-30 20:05:18 -0700 (Fri, 30 Oct 2009) 159 Convert itcontrol GOSUB block into items_menu_control() SUB Fixed a couple cosmetic bugs with item menu PageUp/PageDown support. Removed unused atkIDs() cache --- U wip/game_udts.bi U wip/menustuf.bas U wip/menustuf.bi ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Plan for bigger walkabouts
I just posted a scheme over at http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Talk:Plan_for_raising_sprite_frame_limits Which might be pertinent ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
