Re: [Ohrrpgce] SVN: teeemcee/3223 Empty the sprite cache when leaving the sprite editor again, clearing th
On Tue, Dec 22, 2009 at 08:24:52AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2009-12-22 08:24:52 -0800 (Tue, 22 Dec 2009) > 201 > Empty the sprite cache when leaving the sprite editor again, clearing the box > border cache before doing so. Also, sprite_empty_cache no longer frees leaked > sprites, in case they're not actually leaked. Aha! The box border cache! That explains why the crash was happening where it was. I would go into the attack editor or enemy editor after having drawn a new sprite, and try to add a new set, and it must have been crashing trying to draw the box border on the "do you want to add another set" pop up question. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Problem starting gfx_directx
I was just testing out a windows build with gfx_directx gfx_sdl on a computer with directx 9.0c installed (according to dxdiag). When I run game.exe it says: "This application has failed to start because d3dx9_41.dll was not found. Re-installing the application may fix this problem." When I click okay on it, then game.exe starts up okay falling back on gfx_sdl Any idea why this might happen? --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Problem starting gfx_directx
On Tue, Dec 22, 2009 at 09:01:07PM -0800, Jay Tennant wrote: > > From: Ralph Versteegen > > Sent: Tuesday, December 22, 2009 10:35 PM > > > 2009/12/23 James Paige : > > > I was just testing out a windows build with gfx_directx gfx_sdl on a > > > computer with directx 9.0c installed (according to dxdiag). When I run > > > game.exe it says: > > > > > > "This application has failed to start because d3dx9_41.dll was not > > > found. Re-installing the application may fix this problem." > > > > > > When I click okay on it, then game.exe starts up okay falling back on > > > gfx_sdl > > > > > > Any idea why this might happen? > > > > > > --- > > > James Paige > > d3dx9_41.dll is one of many dll's that microsoft has released to patch the > d3dx library. A solution to this would be obtaining the latest dx runtime on > your computer, available at: > http://www.microsoft.com/downloads/details.aspx?FamilyID=2da43d38-db71-4c1b-bc6a-9b6652cd92a3&displaylang=en Interesting. I had mistakenly assumed that directx updates got included along with the authomatic Microsoft Updates. > An alternative would be compiling the backend with static linking the d3dx > library, which was available in the december 2004 dx sdk. This will remove > dependencies, but will increase the dll size by about 500kb. That is probably for the best. The extra 500k is a bummer, but Oh-well --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] I declare a vendetta against BYREF
On Thu, Dec 24, 2009 at 03:59:15AM +1300, Ralph Versteegen wrote: > I am now sure that defaulting to BYREF is pure evil, and we should > make OPTION BYVAL a priority. Plus, I'm getting sick of typing > hundreds of explicit BYVALs. I like that goal. I have been making an effort to be explicit about integer arguments already. I was reading the FreeBasic docs about BYVAL and OPTION BYVAL, and I am uncertain about a couple things. A BYVAL default for integers and ptrs is a no-brainer, and I understand the quirks regarding BYVAL strings, but what I don't know is: * Does BYVAL on a TYPE make a complete copy of the whole dang structure? * Does OPTION BYVAL apply to TYPEs? * What effect (if any) does BYVAL have on arrays? * Does OPTION BYVAL apply to arrays? --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3229 In the attack and enemy editor, press SHIFT+TAB to remember
On Wed, Dec 23, 2009 at 10:05:52PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2009-12-23 22:05:52 -0800 (Wed, 23 Dec 2009) > 155 > In the attack and enemy editor, press SHIFT+TAB to remember > which record you have selected, and press TAB to toggle between > current and remembered record. I am not 100% sure about the keyboard shortcuts I chose for this, but I needed something to test it with. So far it seems to help me a lot, for example, when I am making a series of very similar enemies, and want to synchronize certain stats, or when I am checking compariative stats between two enemies to try ang gewt difficulty balance right. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3233 Reattempt r3230
On Fri, Dec 25, 2009 at 03:53:57PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2009-12-25 15:53:57 -0800 (Fri, 25 Dec 2009) > 15 > Reattempt r3230 > --- > U wip/allmodex.bas > U wip/gfx.bi Cool. Compiles fine now :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3236 Layers menu: swapping of layers, inserting a new layer between layers, a
On Fri, Dec 25, 2009 at 06:18:38PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2009-12-25 18:18:37 -0800 (Fri, 25 Dec 2009) > 171 > Layers menu: swapping of layers, inserting a new layer between layers, and > moving the heroes/npcs layer. Can't change npcs over heroes ordering from > within the menu though This is awesome! :) ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] gfx_directx, zoom level
On Sun, Dec 27, 2009 at 05:44:30AM +1300, Ralph Versteegen wrote: > 2009/12/27 Jay Tennant : > >> From: Ralph Versteegen > >> Sent: Thursday, December 24, 2009 10:45 AM > >> > >> For a few years, the default zoom level between all the graphics > >> backends has been 2x, and before that, they defaulted to fullscreen. > >> I've always been a bit unsure about that default, and unhappy that > >> there was no way to resize the window without using a commandline > >> option. I've heard complaints that 2x is too small, especially on > >> large monitors. > >> > >> Now gfx_directx lets the user resize the window to any resolution. > >> Unfortunately the options to set the size to an integer multiple of > >> 320x200, from earlier versions, are no longer there, but Jay says he > >> will work on a replacement. Anyway, Jay set the default at 3x zoom. > >> I'm finding this annoying in Custom, where it takes up the whole of my > >> small monitor. If we want to try using it as the default, we probably > >> should change the zoom to 2x to avoid annoying other people? I do find > >> 3x or fullscreen better for playing. Maybe Custom and Game could use > >> different defaults. > >> > >> I really wish we had preference files and a configuration screen. > > > > What if there were an ascii-text based custom.ini and game.ini? A list of > > preferences could be contained and loaded from either the backends or the > > engine. If loaded from the backends, they could also save their last state > > as the default for when the app runs next. So if a user runs game.exe at > > 960x600 in the upper-left corner of their screen with smooth rendering, the > > next time the app boots, it will attempt to build the window at 960x600 in > > the upper-left corner with smooth rendering, etc. > > > > We could write a set of standard interfaces, such as: > > int gfx_QueryPreferences(gfx::Preferences* pPreferences, const char* > > szFile); > > int gfx_SavePreferences(gfx::Preferences* pPreferences, const char* szFile); > > > > And if the engine is loading preferences (which would make more sense), a > > set of interfaces could communicate with the backend: > > int gfx_SetPreferences(gfx::Preferences* pPreferences); > > int gfx_GetPreferences(gfx::Preferences* pPreferences); > > > > The Preferences structure could contain state about width, height, top-left > > window corner position, full-screen state, smoothing state, screenshot > > format, vsync, etc. Not all the data would need to be used by all the > > backends. Any function that fails returns 0. Then we could move > > command-line options to the engine for setting preferences for uniform > > functionality. > > Yes, I agree completely. I've been meaning to suggest this for a few > weeks, when I have time I'll talk about it in more detail. The engine > should read/write the files and communicate with the backends. > Probably the preference files should store options for each backend > separately. I am on board for this too. In the olden-days I was uncomfortable with a prefs file, but my reasons for opposing it have long since all melted away. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3244 Change the default graphics backend on Windows to gfx_sdl, and mention g
On Sat, Dec 26, 2009 at 09:17:39AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2009-12-26 09:17:39 -0800 (Sat, 26 Dec 2009) > 189 > Change the default graphics backend on Windows to gfx_sdl, and mention gfx_fb > bugs avoided in whatsnew.txt. Note: It seems that the default nightly is not > part of the distrib system in svn. Right. The default nightly is a symlink on my web server. I have updated it to point to the ohrrpgce-wip-sdl-sdl.zip --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3255 Add script error level option in Custom. While upgrading a game, a popup
On Mon, Dec 28, 2009 at 08:56:20AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2009-12-28 08:56:20 -0800 (Mon, 28 Dec 2009) > 157 > Add script error level option in Custom. While upgrading a game, a popup > message asks whether to set the error level to the recommended setting. A new > trend? Interesting. I think letting the game author set a default reporting level in custom is good, but I have my doubts about this prompting at upgrade time. Its a bit confusing. I even felt confused by it, and that was *after* I read this commit message. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/3265 gfx_directx backend, v1.5. Resolved a bug where boxes would flash, ie. w
On Tue, Dec 29, 2009 at 11:55:53PM -0800, subvers...@hamsterrepublic.com wrote: > jay > 2009-12-29 23:55:53 -0800 (Tue, 29 Dec 2009) > 225 > gfx_directx backend, v1.5. Resolved a bug where boxes would flash, ie. when > custom starts up and asks if you want more error reports. Not submitting > code--it's getting very ugly, and I'm in the middle of cleaning up the code. > --- > U wip/gfx_directx.dll No need to be embarrassed about committing ugly code. I have more than my share of it in the repository already :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/3256 New backend interfaces, updated. Added GFX_PREFERENCES as a preference s
On Thu, Dec 31, 2009 at 07:11:41AM +1300, Ralph Versteegen wrote: > 2009/12/29 : > > jay > > 2009-12-28 16:02:34 -0800 (Mon, 28 Dec 2009) > > 146 > > New backend interfaces, updated. Added GFX_PREFERENCES as a preference > > structure. Added interfaces: gfx_SetPreferences() and gfx_GetPreferences(). > > --- > > U wip/gfx.new.h > > ___ > > Ohrrpgce mailing list > > ohrrpgce@lists.motherhamster.org > > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > > > Wait, I don't think that this is a good idea. The more complicated > idea of a list of key-value pairs is much more flexible. Most of the > things that you've put in GFX_PREFERENCES are gfx_directx specific, > and you've left out things from other backends, like zoom. And it's > clearly beneficial to be able to add a new option to a backend without > having to update all the backends. > > Using key-values pairs doesn't mean having to use gfx_setoption or > similar. We could modify gfx_Get/SetPreferences to work on an actual > list. > > Also (in response to the next commit), yes, parsing command line > options and reading preferences is very similar, and the intention was > to read preferences and then pass them to the backend with > gfx_setoption, but if gfx_setoption is removed, we would still need > some way to figure out which commandline options should be sent to/are > parsed by the backend. What's the plan if you remove gfx_setoption, to > hardcode a list of options for the graphics backend? I've been > thinking that we should go down this route anyway, though it seems > undesirable. Because command-line options should override config file options... --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/3256 New backend interfaces, updated. Added GFX_PREFERENCES as a preference s
On Thu, Dec 31, 2009 at 07:36:13AM +1300, Ralph Versteegen wrote: > 2009/12/31 Mike Caron : > > Just out of curiosity, what's wrong with something like: > > > > GetPrefInt(name as string, optional section as string = "default") as > > integer > > > > Etc. > > > > -- > > Mike Caron > > Called from within the backend? > > Seems fine, but > 1) the backend can parse its own damn ints I disagree. String parsing is most definitely not a backend task. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3275 Fix menu bit duplication and add some lists.
On Sat, Jan 02, 2010 at 06:01:33AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-02 06:01:33 -0800 (Sat, 02 Jan 2010) > 108 > Fix menu bit duplication and add some lists. > > Does anyone know what's causing the big gaps after lists? > --- > U wip/docs/plotdict.xml Not me :( ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/3256 New backend interfaces, updated. Added GFX_PREFERENCES as a preference s
On Sat, Jan 02, 2010 at 05:15:53AM +1300, Ralph Versteegen wrote: > 2009/12/31 James Paige : > > On Thu, Dec 31, 2009 at 07:36:13AM +1300, Ralph Versteegen wrote: > >> 2009/12/31 Mike Caron : > >> > Just out of curiosity, what's wrong with something like: > >> > > >> > GetPrefInt(name as string, optional section as string = "default") as > >> > integer > >> > > >> > Etc. > >> > > >> > -- > >> > Mike Caron > >> > >> Called from within the backend? > >> > >> Seems fine, but > >> 1) the backend can parse its own damn ints > > > > I disagree. String parsing is most definitely not a backend task. > > > > --- > > James > > Heh, it just seems like an unnecessary extra function. My reply: > string parsing is an extremely common computer program task, and > backends are programs. It's just a call to atoi. This is starting to > sound like a holy war. I think my complaint is a reasonably scientific one. Although string-to-integer conversion is a common tas, there is more than one way to do it. Consider the differences between C++'s atoi and FreeBasic's valint, differences in how they handle bad input, whether or not round decmals or fail on decmals, whether they tolerate trailing garbage, etc. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3277 Add sprite_new_from_buffer and palette16_new_from_buffer, from an old pa
On Sat, Jan 02, 2010 at 07:06:01AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-02 07:06:01 -0800 (Sat, 02 Jan 2010) > 97 > Add sprite_new_from_buffer and palette16_new_from_buffer, from an old patch > from James, modified. > --- Groovy :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3244 Change the default graphics backend on Windows to gfx_sdl, and mention g
On Tue, Jan 05, 2010 at 12:00:37AM +1300, Ralph Versteegen wrote: > 2009/12/27 James Paige : > > On Sat, Dec 26, 2009 at 09:17:39AM -0800, subvers...@hamsterrepublic.com > > wrote: > >> teeemcee > >> 2009-12-26 09:17:39 -0800 (Sat, 26 Dec 2009) > >> 189 > >> Change the default graphics backend on Windows to gfx_sdl, and mention > >> gfx_fb bugs avoided in whatsnew.txt. Note: It seems that the default > >> nightly is not part of the distrib system in svn. > > > > Right. The default nightly is a symlink on my web server. I have updated > > it to point to the ohrrpgce-wip-sdl-sdl.zip > > > > --- > > James Paige > > Also, some of the old nightlies need to be deleted: > > http://hamsterrepublic.com/ohrrpgce/nightly/ Ah, done. Thanks for spotting that. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3287 Fix the looping sound import problem, which was a problem in gfx_sdl
On Wed, Jan 06, 2010 at 12:32:27AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-06 00:32:24 -0800 (Wed, 06 Jan 2010) > 260 > Fix the looping sound import problem, which was a problem in gfx_sdl > > For some reason calling SHELL causes SDL to not send some key up events on > Windows when not compiled with -s console. I've worked around this by > bringing back the old SDL_GetKeyState code :( > --- > U wip/gfx_sdl.bas H. I wonder if we could use EXEC instead of SHELL in that case... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3288 Fix graphic scrambling when leaving the sprite editor while the sprite b
On Wed, Jan 06, 2010 at 01:35:32AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-06 01:35:32 -0800 (Wed, 06 Jan 2010) > 251 > Fix graphic scrambling when leaving the sprite editor while the sprite buffer > is rotated > > The fact that the rotated sprite buffer clipping hack was placed in > writeundospr unnerves me, and I think I'll be giving the sprite editor a > little more distance Heh, I guess I am stuck with it then :) Cleanup of the sprite editor is still very much a work in progress :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: jay/3293 gfx_sdl, updated interfaces. Working input mechanism, though lacks suppo
On Wed, Jan 06, 2010 at 11:38:11AM -0800, subvers...@hamsterrepublic.com wrote: > jay > 2010-01-06 11:38:11 -0800 (Wed, 06 Jan 2010) > 281 > gfx_sdl, updated interfaces. Working input mechanism, though lacks support > for mouse wheel and joystick support. I don't know if sdl supports mouse > wheel. It supports joystick--I just didn't implement it yet or expose the > methods. SDL sends mouse wheel events as button presses. button 1 = left click button 2 = middle click or wheel click button 3 = right click button 4 = wheel up button 5 = wheel down button 6 = horizontal wheel left (I think) button 7 = horizontal wheel right (I think) button 8 = extra button (works for my thumb button) button 9+ probably work too, if you have one of those ostentatous Logitech 14-button mice :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3297 Delete ancient and unused copy of thirdparty.hsi (what on earth was it d
On Thu, Jan 07, 2010 at 02:28:16AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-07 02:28:16 -0800 (Thu, 07 Jan 2010) > 129 > Delete ancient and unused copy of thirdparty.hsi (what on earth was it doing > there?) and update viking.hsi to fix compile warning It was in Fenrir's zip file, and I didn't bother to check if it was actually used :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3301 Add "slice child" command
On Thu, Jan 07, 2010 at 09:45:01AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-07 09:45:01 -0800 (Thu, 07 Jan 2010) > 25 > Add "slice child" command > --- > U wip/docs/plotdict.xml > U wip/game.bas > U wip/plotscr.hsd > U wip/testgame/slicetest.hss > U wip/testgame/slicetest.rpg > U wip/whatsnew.txt > U wip/yetmore.bas Nice! So obvious. Good addition. :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3313 Fix a few distrib script problems.
On Sat, Jan 09, 2010 at 02:39:32PM +1300, Ralph Versteegen wrote: > 2010/1/9 Ralph Versteegen : > > 2010/1/9 : > >> james > >> 2010-01-08 13:42:19 -0800 (Fri, 08 Jan 2010) > >> 271 > >> Fix a few distrib script problems. > >> * gfx_directx.dll was not being included in the zip file > >> * IMPORTANT-nightly.txt was being included even though this isn't a nightly > >> * several commands were redirecting > NUL which could have hidden some > >> error messages (hypothetically) > >> --- > >> U rel/ypsiliform/distrib.bat > > > > I included IMPORTANT-nightly.txt on purpose, as it is still > > potentially important for anyone upgrading from a nightly to > > Ypsiliform. I suggest that we archive its contents somewhere so that > > people who skip a stable release can see what they missed. We could > > move the contents to the wiki, or keep a whatsnew.txt style log and > > stick it in the nightlies folder. > > ...which is better than including it with the stable release, I guess. > I'd prefer if it were linked to on the Downloads page, "Notes for > people upgrading from nightlies" That sounds good to me. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3316 Ack! Wiki mirror script was also mirroring my entire album collection, w
On Sat, Jan 09, 2010 at 01:31:04PM +1300, Ralph Versteegen wrote: > 2010/1/9 : > > james > > 2010-01-08 15:53:40 -0800 (Fri, 08 Jan 2010) > > 196 > > Ack! Wiki mirror script was also mirroring my entire album collection, > > which explains why the script was > > taking hours to finish and took up six gigabytes more disk space than it > > was supposed to! > > That's hilarious :) Actually, it wasn't as bad as I thought. Not the full 6 gb, but it was indeed getting some stuff it shouldn't. > But why was it mirroring thehamsterwheel.net? Don't you have to > explicitly specify other domain names to crawl them? httrack can be configured to either whitelist or blacklist sites. I am doing a bit of both, which might be the wrong approach. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3320 Fix the rather embarrasing missing "Quit Editing" from the main menu in
On Sun, Jan 10, 2010 at 07:37:38PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-01-10 19:37:37 -0800 (Sun, 10 Jan 2010) > 93 > Fix the rather embarrasing missing "Quit Editing" from the main menu in > custom in ypsiliform We'll do a a ypsiliform+1 in a couple weeks for this and any other little things that crop up. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3309 Create branch of Ypsiliform stable release
On Tue, Jan 12, 2010 at 12:00:14AM +1300, Ralph Versteegen wrote: > 2010/1/9 : > > james > > 2010-01-08 09:30:01 -0800 (Fri, 08 Jan 2010) > > 43 > > Create branch of Ypsiliform stable release > > --- > > A rel/ypsiliform/ > > James - Unbelievable! Somehow we always manage to distribute the wrong > copy of plotdictionary.html. In this case, you somehow managed to > branch from r3307 instead of r3308! Frustrating :P --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] speaking of C++
Speaking of C++, I was poking around in the fb2c++ subversion lately. I made a few minor fixes to make it compile on linux, but I wasn' sure if that repository is what you were still using. Also, I was looking at the freebasic subversion log, and notice that v1ctor has recently started a lot of work on a branch for the gcc emitter. Doesn't look usable yet, but does look interesting. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Sprite editor: rewrite?
On Thu, Jan 21, 2010 at 11:46:48AM +1300, Ralph Versteegen wrote: > The sprite editor needs to be updated to: > -use Frames instead of the old modex crud > -support 256 colour palettes > -support resizing frames from within the editor > -work on elements of SpriteSets instead of old-style frame arrays > -completely decouple from the current spriteset browser, which will be > thrown out > -variable resolution support would be nice > > At least it looks like sprite_editor is already mostly separated from > the sprite set browser, and everything is nice subified. But I don't > know how to answer this: > > Would it be easier to make these changes incrementally, or to start > from scratch and gradually update and move over components of the > existing editor? Good question. I normally favor incremental cleanup, but I think the sprite editor might be a case where we will be better off with a rewrite. I was thinking about using a saved slice collection to re-impelement the sprite editor's interface, but we don't have finalized slice collection saving/loading support yet... And I haven't worked on slice collection saving and loading because I haven't heard any agreement on declaring the RELOAD format stable or not. (Incidentaly that is the same thing that is stopping me from working on the new SAV format and working on the Editor Editor) --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Sprite editor: rewrite?
On Thu, Jan 21, 2010 at 02:01:34PM +1300, Ralph Versteegen wrote: > 2010/1/21 James Paige : > > On Thu, Jan 21, 2010 at 11:46:48AM +1300, Ralph Versteegen wrote: > >> The sprite editor needs to be updated to: > >> -use Frames instead of the old modex crud > >> -support 256 colour palettes > >> -support resizing frames from within the editor > >> -work on elements of SpriteSets instead of old-style frame arrays > >> -completely decouple from the current spriteset browser, which will be > >> thrown out > >> -variable resolution support would be nice > >> > >> At least it looks like sprite_editor is already mostly separated from > >> the sprite set browser, and everything is nice subified. But I don't > >> know how to answer this: > >> > >> Would it be easier to make these changes incrementally, or to start > >> from scratch and gradually update and move over components of the > >> existing editor? > > > > Good question. I normally favor incremental cleanup, but I think the > > sprite editor might be a case where we will be better off with a > > rewrite. > > > > I was thinking about using a saved slice collection to re-impelement the > > sprite editor's interface, but we don't have finalized slice collection > > saving/loading support yet... > > Neat. That should mean automatic resolution independence as slices are > aligned to the sides of the screen, right? I think that was the whole > point of Seth originally using them in FMF. Speaking of resolution independance, what are your goals for that? Some things you said earlier made me think you were talking about changing the resolution while the program is running, which I am uncomfortable with. I am also worried about large resolutions, because those could become a problem on some platforms that I would like to target in the future. For example, iPhone has a max rsolution of 480x320 in landscape mode (although it might have some hardware scaling support that would midigate that) and the Wii has a max resolution of 640x480 (I think). Also, the max resolutions on android phones seem to vary, but are still pretty low compared to desktops. Are we going to choose a maximum? If so, what should it be, and how do we handle platforms that can't support it? (Maybe in Custom, on the screen where you choose your game's resolution, it could show a list of supported platforms capable of the resolution you requested?) > > And I haven't worked on slice collection saving and loading because I > > haven't heard any agreement on declaring the RELOAD format stable or > > not. > > > > (Incidentaly that is the same thing that is stopping me from working on > > the new SAV format and working on the Editor Editor) > > > > --- > > James Paige > > I'm pretty sure that the file format and loading/saving functions is > done. What's not is some of the rest of the API (particularly RPath?). > I don't know if this is actually a problem. Whenever I have an excuse > to use RELOAD (which was going to be for the new map format, but > that's stalled due to lack of feedback), I'll just finish off bits of > RELOAD as I need them. Also, the TODO list on RELOAD page on the wiki > looks out of date. Ah, okay. Well, as long as the core format and the saving and loading are stable, I can start working with that. I don't actually undertsand RPath well enough to know whether I would want to use it :) > Also, I meant to say: because we couldn't come to agreement on the new > file formats for sprites & animations, I may just whip up something > temporary while I play around with it. I ought to try to write the > competing proposals up simply rather than leaving people to dig > through that enormous talk page on the wiki. I don't have any strong preferences for the sprite and animation formats. A format with a working implementation is worth more than two better formats that are still in planning :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3344 Change the way that drawmap/setmapdata calculate screen position. Resolu
On Wed, Jan 20, 2010 at 10:50:25PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-20 22:50:25 -0800 (Wed, 20 Jan 2010) > 146 > Change the way that drawmap/setmapdata calculate screen position. Resolution > independence in drawmap; overload for drawing a map covering a frame. Sweet! This sounds like what is needed to do the OTHER kind of Map Slice, the one that can show an arbitrary non-current map within a smaller-than-screen-size slice --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3345 For fun: gfx_sdl lets you resize the window when resolution is unlocked
On Wed, Jan 20, 2010 at 10:50:27PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-20 22:50:27 -0800 (Wed, 20 Jan 2010) > 186 > For fun: gfx_sdl lets you resize the window when resolution is unlocked > (press !+r). Works surprisingly well. Added gfx_getresize and > gfx_setresizable. I stress that these are temporary. > --- Haha! This wins the prize for must fun new debug key. CTRL+F1 teleport mode is crying right now :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3347 Rewrite walkabout map wrapping for both resolution independence and the
On Wed, Jan 20, 2010 at 10:50:31PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-01-20 22:50:31 -0800 (Wed, 20 Jan 2010) > 305 > Rewrite walkabout map wrapping for both resolution independence and the > future problems caused by attaching slices to NPCs, etc. I have replaced a > mess of code with a big conceptual mess. Nothing that can really be done > about it. > > Also, somehow wrapping got turned off in the wrapping test map in test.rpg I probably checked that in by accident while I was fixing some vehicle bugs a while back. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Sprite editor: rewrite?
On Sat, Jan 23, 2010 at 05:25:28AM +1300, Ralph Versteegen wrote: > 2010/1/22 James Paige : > > On Thu, Jan 21, 2010 at 02:01:34PM +1300, Ralph Versteegen wrote: > >> 2010/1/21 James Paige : > >> > On Thu, Jan 21, 2010 at 11:46:48AM +1300, Ralph Versteegen wrote: > >> >> The sprite editor needs to be updated to: > >> >> -use Frames instead of the old modex crud > >> >> -support 256 colour palettes > >> >> -support resizing frames from within the editor > >> >> -work on elements of SpriteSets instead of old-style frame arrays > >> >> -completely decouple from the current spriteset browser, which will be > >> >> thrown out > >> >> -variable resolution support would be nice > >> >> > >> >> At least it looks like sprite_editor is already mostly separated from > >> >> the sprite set browser, and everything is nice subified. But I don't > >> >> know how to answer this: > >> >> > >> >> Would it be easier to make these changes incrementally, or to start > >> >> from scratch and gradually update and move over components of the > >> >> existing editor? > >> > > >> > Good question. I normally favor incremental cleanup, but I think the > >> > sprite editor might be a case where we will be better off with a > >> > rewrite. > >> > > >> > I was thinking about using a saved slice collection to re-impelement the > >> > sprite editor's interface, but we don't have finalized slice collection > >> > saving/loading support yet... > >> > >> Neat. That should mean automatic resolution independence as slices are > >> aligned to the sides of the screen, right? I think that was the whole > >> point of Seth originally using them in FMF. > > > > Speaking of resolution independance, what are your goals for that? > > Honestly, just to do something interesting for a couple days. I'm not > even aiming to finish this by the next release, although it's moving > along well. Feeling a bit bored, I decided to start on a whole lot of > big wishlist features at once. Haven't thought too hard about detailed > goals for this. We could do with a Plan. Fair enough :) > > Some things you said earlier made me think you were talking about > > changing the resolution while the program is running, which I am > > uncomfortable with. > > Yes, but only in certain circumstances: > -running/quitting a game That make sense. > -menus in Custom which have been written to handle it (and if they can > handle it, it would be nice to keep the ability to resize the window > as you can currently do with !+r. It seems that this is actually > pretty easy to do if you plan ahead. However, adding the same > resizability to all the other backends will probably be > hard/impossible. But that doesn't matter, it would only be an optional > feature anyway.) Like for a bigger map editor, right? > Changing the resolution in the middle of a game is just for debugging. Okay, that is good. My main concern about that was that resolution changing can wreck havoc with full-screen mode, even between well-supported resolutions. > > I am also worried about large resolutions, because those could become a > > problem on some platforms that I would like to target in the future. For > > example, iPhone has a max rsolution of 480x320 in landscape mode > > (although it might have some hardware scaling support that would > > midigate that) and the Wii has a max resolution of 640x480 (I think). > > Also, the max resolutions on android phones seem to vary, but are still > > pretty low compared to desktops. Are we going to choose a maximum? If > > so, what should it be, and how do we handle platforms that can't support > > it? (Maybe in Custom, on the screen where you choose your game's > > resolution, it could show a list of supported platforms capable of the > > resolution you requested?) > > That is exactly what I wanted to do. > I think that if someone has a good reason to use a higher resolution, > we shouldn't really set an artificial limit preventing it. They would > know exactly they're giving up in exchange (though it would help if we > actually had ports to some of these platforms :). Yes :) "Warning: Your chosen resolution of 800x600 will prevent your game from running on certain platforms... hypothetically in the future probably" > >> > And I haven't worked on slice collection saving and loading because I > >> > have
Re: [Ohrrpgce] RELOAD
On Fri, Jan 22, 2010 at 06:09:11PM +, Mike Caron wrote: > This is related to the stuff in the screen resolution conversation, but > tangential enough to start a new email: > > I was thinking about RPath, and I realize it would be really complex, perhaps > more than is justified. Instead, I was thinking about something close to a > Saxon-style API for parsing a RELOAD file in bulk. > > Basically, the RELOADer goes through the file, and through either a call back > or a state machine, asks the caller whether it cares about the node. If so, > it descends into it. Otherwise, it skips it. > > This would be fairly easy to implement, and tends to be very fast. It also > offsets the logic of deciding which nodes are important to the caller > > I wrote an RSS reader recently using a Saxon API, and it was deceptively > easy. I think it would be worth while looking in to. > > If you guys agree, I could start working on it. > > -- > Mike Caron I don't know anything about RPath or Saxon. I am pretty happy with manually handling nodes given a starting parent node. I did have to add one function to reload.bas to make my slice collection loading work. The FindChildByName() function does a depth-first search from a starting node. I added GetChildByName() which does not recurse and only searches the immediate children of the given node. For example, I have the X value of a slice in a child named "X" When I am loading it, I want to search for a child named "X", but if it is not found for some reason, I do NOT want to to recurse into the child node named "children" and find any of the nodes named "X" of any of its numerous children. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] slice grid idea
So I have been thinking about using slice collections (*) for menu layouts, and I am thinking that some kind of GridSlice would be useful. The idea is that a gridslice is divided into even-sized rows and columns. Children of the grid automatically get moved to fill the grid squares. Suppose I want to reproduce the load game screen. I would create two slice collections, one according to the "Load Game Screen" template and one according to the "Load Game Info Panel" template. The Load Game Screen template would require a slices marked as "sl_load_new_button" "sl_load_exit_button" and "sl_load_grid" (not sure about the names, I am just making them up at the moment) The Load Game Info Panel would be fit into the grid slots in the other collection. it would have slots for the hero pictures, current map, current time, etc... ...actually, it would probably contain another grid for "Load Game Info Panel Hero Previews" which would be automatically filled from another slice collection that would allow walkabout, or battle or portrait sprites, and maybe names and stats (but to reproduce the current load screen it would just have the hero battle picture) Anyway, how do y'all like the idea of a slice grid? I think it would be a nice alternative to painstakingly arranging lots of same-sized container slices? (think of the master palette in the sprite editor That would be hell to convert to slices with no GridSlice) * I like saying "slice collection" a heck of a lot better than I like saying "screen layout". I am thinking of changing the name of the menu in custom... --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] [Bug 812] Occasional Crash After Using Ctrl+F in Graphics Editors
On Thu, Jan 28, 2010 at 03:35:08AM -0800, bugzilla-dae...@karnov.dreamhost.com wrote: > > http://rpg.hamsterrepublic.com/bugzilla/show_bug.cgi?id=812 > > --- Comment #8 from Ralph Versteegen 2010-01-28 03:35:05 > PST --- > (In reply to comment #7) > > Haha. So here is what was happening. I noticed that if I pressed ESC to > > cancel > > the palette browser, no crash, but if I pressed ENTER to choose a palette, > > it > > would crash. > > > > The enter keypress was getting re-read and triggering grabbing of a color. > > This > > would cause it to grab a pixel color from the old palette, which would > > (usually) not be present in the new palette. > > > > Madness. > > I'm very glad you fixed that, because I probably would have spent hours trying > to wrap my head around how the sprite editor's palette-shunting works before > looking too closely at the exact crash cause :) Yeah, I only spent about 20 minutes trying to remember how the editor handles palettes before I just tracked down the crash instead ;) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] slice grid idea
On Fri, Jan 29, 2010 at 12:31:08AM +1300, Ralph Versteegen wrote: > On 28 January 2010 07:53, James Paige wrote: > > > > The Load Game Screen template would require a slices marked as > > "sl_load_new_button" "sl_load_exit_button" and "sl_load_grid" (not sure > > about the names, I am just making them up at the moment) > > I assume these would not all be mandatory I guess the templates need a few different levels of reuirement for the included elements * Mandatory - Template will produce a run-time warning if it lacks this. * Suggested - Template will produce a save-time warning in the editor if it lacks this * Optional - Has meaning for this template, but isn't required. > This GridSlice sounds like a good idea (although something big remains > unexplained when going from "Children of the grid automatically get > moved" to "The Load Game Info Panel would be fit into the grid slots") I am working on an implementation now. My plan is that children of the grid will be positioned relative to a grid cell instead of relative to the whole parent. That means that children with Fill enabled will automatically fill the grid cell. Cells will be numbered like 0 1 2 3 4 5 6 7 8 If the grid has more children than it has cells, the extra children will be treated as if they are "hidden" (although their visible property will not actually be changed) It remains to be seen if the Grid will have reasonable performance or not, but I am optimistic, at least for moderately sized grids. > But I think that in the case of the load/save menus, would you would > want is yet another type of new slice: a MenuSlice. Recall that we > planned to increase the number of save slots on the load/save menu. > MenuSlices can have an unlimited number of children, of which a > limited number are displayed at once, in a grid. They might have > scroll bars, and the order in which items are traversed is selectable > (row major or column major). We could allow scrolling smoothly instead > of in jumps. There is currently a partial implementation of something called a MenuSlice. I think Mike wrote it. I understand it to be for reproducing menus, although I am not sure if those should be hard-coded into slices.bas or done as compound slices Andyway, I like the idea of a ScrollingSlice. I was indeed thinking of the ability to show more than 4 save slots on the save/load screens, although at the moment I had been envisioning just making them more compact. > I think what really needs discussing is how to go from slice > collections to replace builtin menus. Labelling slices to give them > special meaning seems like a good idea, but I'm also envisioning > 'protoslices' - (noneditable?) placeholder slices added to a slice > collection which ingame are replaced by one or multiple slices - in > your load menu, the grid slice might have one child marked " Game Panels>". Yes, that sounds a lot like what I have in mind. A protoslice would be a placeholder for an engine-created slice or an instance of some other slice template. I am still waffling a bit over whether these slices should be labelled with strings or with slice lookup constants. I am leaning towards constants. > Also, I was planning to add something like a 'View' or 'Clipping' > slice, which clips the drawing of its children to a rectangular area, > using view frames. Not sure if it's the most elegant solution, but it > seems like a simplest way to enable drawing just part of a sprite or a > mapslice. Split screen would be achieved by parenting slices for two > different maps to two different view slices. But... how on earth would > you show two parts of the same map at once? That would be great! In fact, with a ClippingSlice, the ScollingSlice would be super-easy to make. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] A module format to add
On Thu, Jan 28, 2010 at 10:52:58PM +1030, David Gowers wrote: > On Thu, Jan 28, 2010 at 9:16 PM, Ralph Versteegen wrote: > > On 28 January 2010 19:26, Mike West wrote: > >> I don't know if you all know about it but there's a new module format for > >> music that is much better than .mod... it's for a tracker called > >> Protrekker, > >> you can find it on Google code (there is a replayer routine). It would be > >> really nice to be able to use those modules in games. I don't know how hard > >> it would be to add support for it I'm not a programmer but if you can that > >> would be great. > >> > > > > We depend on libraries to play music and sound effects. music_sdl uses > > SDL_Mixer which uses MikMod, and music_native uses Audiere which uses > > DUMB. It might be possible to extend Audiere, but SDL_Mixer is > > absolutely horrible when it comes to this sort of thing. You'd have to > > convince these libraries to add Protrekker support. > > > > I wasn't able to find the Google Code project, or almost any mention > > of Protrekker whatsoever. And there's a camera accessory with the same > > name. > > I'm almost certain that Mike is talking about ProTracker XMs, which > should already be supported. I was tempted to ask 'Are you going to > ask for more than 20 maps next?' By the way, I would love to add an XM to the Free Music collection. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3362 Implement GridSlice - diagonosis: Awesome!
[re-sending due to mail server error, sorry if this arives twice] On Thu, Jan 28, 2010 at 04:31:53PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-01-28 16:31:53 -0800 (Thu, 28 Jan 2010) > 233 > Implement GridSlice - diagonosis: Awesome! > Supports filling, padding, and alignment. The only thing it doesn't support yet is hiding children that overflow the grid. It currently just keeps adding rows off the bottom of the grid. > Speed is perfectly reasonable for small numbers of children. > Large numbers of children should be expected to be slow in the current > implementation. Each child has to iterate the list of its siblings to figure out which child index it is. I would expect the time this takes to curve towards slowness. Seems like the thing to do would be to let each slice cache its index. This could be updated each time a parent gains, loses, swaps or sorts children. An cached child index would also greatly optimize the "slice child" plotscripting command, making it just as fast to iterate a slice family with a "for" loop and "slice child" as it currently is to iterate with a "while" loop and "next sibling" The downside is a little extra slowness when adding deleting swapping and sorting slices. Is it worth it? I think probably so, but I hate to guess about this sort of thing :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3365 All slices now support a .Clip property that causes children to be clipp
On Fri, Jan 29, 2010 at 04:28:10PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-01-29 16:28:10 -0800 (Fri, 29 Jan 2010) > 182 > All slices now support a .Clip property that causes children to be clipped. > GridSlice cells support clipping too. > TMC, thanks for allmodex's setclip() which made this easy to do! :) Actually, I said "All slices" but Box borders on RectangleSlice don't clip properly yet, and I have not made any attempt to test if MapSlice clips. SpriteSlices and TextSlices clip awesomely. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3365 All slices now support a .Clip property that causes children to be clipp
On Sat, Jan 30, 2010 at 11:09:13PM +1300, Ralph Versteegen wrote: > On 30 January 2010 13:28, wrote: > > james > > 2010-01-29 16:28:10 -0800 (Fri, 29 Jan 2010) > > 182 > > All slices now support a .Clip property that causes children to be clipped. > > GridSlice cells support clipping too. > > TMC, thanks for allmodex's setclip() which made this easy to do! :) > > --- > > U wip/sliceedit.bas > > U wip/slices.bas > > U wip/slices.bi > > Actually Simon wrote that, so I thought that it was always part of > allmodex? Maybe not. Oh? I had thought it was a new addition. > Are you planning to expose that to scripting with a command to make > any slice clip its children? This is simpler than a separate > ClippingSlice, but I'm not sure whether it makes sense to allow any > slice to clip, especially sprites. What is the size and position of a > sprite? Remember: it will depend on the current frame, and on its > animation state. I do plan on exposing this to scripting, but not until I have them better tested, and I am confident that I am doing them in a sane way. Last night before bed I realized that slices are only clipping inside their first clipping parent, and overflowing any outer clipping grandparents. (but I have an idea for fixing that) All slices have to be clipping aware to make clipping work, so I think it is best to allow all slice types to clip. That is to say, I can't see any advantage to add a secial case to forbid sprites from clipping. I don't see variable sprite size causing a problem. That just means the spriteslice size will change when the animation frame changes, and that is no problem. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3372 Add some comments noting how clipping currently works
On Mon, Feb 01, 2010 at 08:50:29PM +1300, Ralph Versteegen wrote: > On 31 January 2010 09:19, wrote: > > james > > 2010-01-30 12:19:50 -0800 (Sat, 30 Jan 2010) > > 54 > > Add some comments noting how clipping currently works > > --- > > U wip/allmodex.bas > > U wip/allmodex.bi > > setclip is meant to be allmodex-internal and obsolete. The preferred > way to do clipping is to use frame_new_view, but that's much more > painful to use most of the time, so setclip probably won't go away or > become allmodex internal again (it was originally until I fixed box > border drawing)... but I will definitely remove the horrible overloads > which take a page instead of a frame that glorious day we delete the > sprite editor :). Hmmm. I tried fame_new_view first, bit it didn't seem to clip at all, so I wqent with setclip instead... but maybe I was using it wrong, or maybe it was interacting badly with allocatepage? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3365 All slices now support a .Clip property that causes children to be clipp
On Tue, Feb 02, 2010 at 02:49:08AM +1300, Ralph Versteegen wrote: > On 31 January 2010 07:00, James Paige wrote: > > > > I don't see variable sprite size causing a problem. That just means the > > spriteslice size will change when the animation frame changes, and that > > is no problem. > > Well, I already notice a problem: clipping right now is based on a > slice's screen coordinates, which for an animating sprite are not the > same as the position at which it's drawn. Recall the idea that sprite > animations could include frame offsets, which do NOT affect the > 'logical' (slice) position. But none of that is implemented yet. I do remember discussing allowing animating sprites to have different display position and logical position. I always envisioned implementing that with two slices. A container slice with unchanging size that would be the logical position, and it would have a spriteslice child which would be the animating component that could overflow the edges of the logical slice. (And I agree that it would make no sense to clip children of a compound slice of that type) But if I understand correctly, you envision implementing variable animation frame sizes entirely within the sprite, so there would be just one slice, right? > > --- > > James > > OK, I just had a look at this clipping code. Eeek! setclip was not > intended for this kind of over-use. Yeah, tell me about it :) > If you try to attach a RectSlice with a border or a MapSlice to a > clipping parent, you should find that clipping simply fails since > these call setclip themselves when drawing - they are not primitives. > Also, the first thing drawn might also call setclip (from within > allmodex) if it changes wrkpage. > Using frame_new_view would be simpler, safe, and more elegant than > this setclip hackery (this is actually basically what it was intended > for) EXCEPT that it changes the origin of the screen. Hmmm. I guess > we'll just have to switch to views and add an extra offset to slice > position when drawing to undo the double translation. I would be delighted to switch over to frame_new_view. I can give it another shot and see if I can figure out where it wasn't working for me before. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3374 Democracy has spoken.
Heh, Mayors ARE awesome! >:) On Tue, Feb 02, 2010 at 12:08:31AM -0500, Mike Caron wrote: > http://www.mspaintadventures.com/?s=6&p=002586 > > I'm sorry, it had to be done. > > subvers...@hamsterrepublic.com wrote: > >james > >2010-02-01 19:14:50 -0800 (Mon, 01 Feb 2010) > >49 > >Democracy has spoken. > > > >And it said "Zenzizenzic" > >--- > >U wip/whatsnew.txt > >___ > >Ohrrpgce mailing list > >ohrrpgce@lists.motherhamster.org > >http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > -- > Mike > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3374 Democracy has spoken.
Zenzizenzic alarmed me when I first saw it too, but it has really grown on me. Saying it out loud is fun. After z we will loop back to "a". I don't think "aa" "ab" "ac" would be much fun, since then we will be on a-words forever :) For those of you who don't follow CastleParadox, we took a vote on what the z codename would be, rather than me choosing it myself like I usually do (it probably would have been "zimperumpazoo" if I had, but I am also very happy with zenzizenzic) --- James On Tue, Feb 02, 2010 at 01:11:11PM +, Simon Bradley wrote: > Oh dear. I think I'll wait for Aardvark. (What does happen after z?) > > On Tue, Feb 2, 2010 at 3:14 AM, wrote: > > james > > 2010-02-01 19:14:50 -0800 (Mon, 01 Feb 2010) > > 49 > > Democracy has spoken. > > > > And it said "Zenzizenzic" ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3375 Fix a broken null-pointer check in SliceLoadFromFile() which was causing
On Wed, Feb 03, 2010 at 07:45:34AM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-03 07:45:34 -0800 (Wed, 03 Feb 2010) > 125 > Fix a broken null-pointer check in SliceLoadFromFile() which was causing > crashes when trying to load a nonexistant filename. > --- This bug makes me wonder if anybody other than myself has actually seen GridSlice and slice clipping in a action yet? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3375 Fix a broken null-pointer check in SliceLoadFromFile() which was causing
On Fri, Feb 05, 2010 at 03:56:34AM +1300, Ralph Versteegen wrote: > On 04/02/2010, James Paige wrote: > > On Wed, Feb 03, 2010 at 07:45:34AM -0800, subvers...@hamsterrepublic.com > > wrote: > >> james > >> 2010-02-03 07:45:34 -0800 (Wed, 03 Feb 2010) > >> 125 > >> Fix a broken null-pointer check in SliceLoadFromFile() which was causing > >> crashes when trying to load a nonexistant filename. > >> --- > > > > This bug makes me wonder if anybody other than myself has actually seen > > GridSlice and slice clipping in a action yet? > > > > --- > > James > > True! I just had a look: pretty awesome! They are fun :) > I notice that when rectangles with simple line borders are clipped, > they are actually resized (so have a border along their whole edge) > rather than being cut. Well, this is how I wrote it, but it doesn't > seem correct anymore. I wonder whether we rely on that anywhere. I can't think of any place where boxes are intentionally draw over the edge, except maybe the few seconds when a help screen animates up from the bottom. > I've been concentrating solely on the interpreter recently, busy, > lazy, and addicted to Hacker News re interpeter: cool! re lazy/addicted: I know what you mean. after Mike posted that mspaintadventure link I wasted an astonishing amount of time reading it :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Attacks require tags
On Sat, Feb 06, 2010 at 10:11:32AM -0800, Adam Perry wrote: >Is there a way to make attacks require tags? > Yes, No, and Later Yes, you can use advanced chaining to make attacks dependant on tags, but No you can't use a tag to determine whether an attack in your menu is enabled, but Later it will be adding that feature. http://gilgamesh.hamsterrepublic.com/wiki/ohrrpgce/index.php/Plan_for_improved_spell_learning --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] box taxonomy
I have been tracing the evolution of box drawing functions in the ohr biosphere. == allmodex.bas == rectangle fuzzyrect drawbox == common.bas == edgebox edgeboxstyle center_edgeboxstyle centerbox centerfuz emptybox (like drawbox but with thickness, uses rectangle) (Have I missed any?) I was feeling overwhelmed by these, but having sorted them out a little, I fell better. I am going to work on adding support for drawing boxes of all kinds on frames. While I am at it, I might give the edgebox derivatives less crappy names, and maybe eliminate some of them entirely (centerbox and centerfuz, I am lookin' at you!) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] box taxonomy
On Tue, Feb 09, 2010 at 02:02:20AM +1300, Ralph Versteegen wrote: > On 8 February 2010 17:50, James Paige wrote: > > I have been tracing the evolution of box drawing functions in the ohr > > biosphere. > > > > == allmodex.bas == > > > > rectangle > > fuzzyrect > > drawbox > > > > == common.bas == > > > > edgebox > > edgeboxstyle > > center_edgeboxstyle > > centerbox > > centerfuz > > > > emptybox (like drawbox but with thickness, uses rectangle) > > > > (Have I missed any?) > > > > > > > > I was feeling overwhelmed by these, but having sorted them out a little, > > I fell better. I am going to work on adding support for drawing boxes of > > all kinds on frames. > > > > While I am at it, I might give the edgebox derivatives less crappy > > names, and maybe eliminate some of them entirely (centerbox and > > centerfuz, I am lookin' at you!) > > > I (still) feel overwhelmed by the number of box functions. I > definitely think we need to get rid of some. In my experience > centerbox/fuz usually seem to make code harder to modify. My plan is that *eventually* the centerbox cruft will be replaced by slices that use the appropriate anchors and alignment if they need to be centered. In the short range, I will probably convert centerbox and centerfuz calls into center_edgeboxstyle calls (after giving it a much shorter and craptacular name) > I take back anything I ever said about not providing overloads for > allmodex graphics functions to draw onto a frame. My plan was to implement those on the weekend. Instead I spent almost the whole two days reading mspaintadventures.com ... dang you Mike! --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] box taxonomy
I know. I figure if I read it all, maybe I can get it out of my system. Last night I was dreaming it MSPA motif all night. When my alarm rang this morning I tried to capchalogue my pillow in an attempt to eject the alarm from my sylladex. --- James On Mon, Feb 08, 2010 at 07:42:47PM +, Mike Caron wrote: > Look, it's best to get MSPA out of the way now, so that you're not stuck > reading it at 4am, knowing that you have to get up in three hours, but you > can't go to bed because Andrew Hussie just introduced *another* new, > interesting character! > > My name is Mike, and I read MSPaint Adventures. > > "Hello Mike!" > --Original Message-- > From: James Paige > Sender: ohrrpgce-boun...@lists.motherhamster.org > To: ohrrpgce@lists.motherhamster.org > ReplyTo: ohrrpgce@lists.motherhamster.org > Subject: Re: [Ohrrpgce] box taxonomy > Sent: Feb 8, 2010 1:53 PM > > On Tue, Feb 09, 2010 at 02:02:20AM +1300, Ralph Versteegen wrote: > > On 8 February 2010 17:50, James Paige wrote: > > > I have been tracing the evolution of box drawing functions in the ohr > > > biosphere. > > > > > > == allmodex.bas == > > > > > > rectangle > > > fuzzyrect > > > drawbox > > > > > > == common.bas == > > > > > > edgebox > > > edgeboxstyle > > > center_edgeboxstyle > > > centerbox > > > centerfuz > > > > > > emptybox (like drawbox but with thickness, uses rectangle) > > > > > > (Have I missed any?) > > > > > > > > > > > > I was feeling overwhelmed by these, but having sorted them out a little, > > > I fell better. I am going to work on adding support for drawing boxes of > > > all kinds on frames. > > > > > > While I am at it, I might give the edgebox derivatives less crappy > > > names, and maybe eliminate some of them entirely (centerbox and > > > centerfuz, I am lookin' at you!) > > > > > I (still) feel overwhelmed by the number of box functions. I > > definitely think we need to get rid of some. In my experience > > centerbox/fuz usually seem to make code harder to modify. > > My plan is that *eventually* the centerbox cruft will be replaced by > slices that use the appropriate anchors and alignment if they need to be > centered. In the short range, I will probably convert centerbox and > centerfuz calls into center_edgeboxstyle calls (after giving it a much > shorter and craptacular name) > > > I take back anything I ever said about not providing overloads for > > allmodex graphics functions to draw onto a frame. > > My plan was to implement those on the weekend. Instead I spent almost > the whole two days reading mspaintadventures.com ... dang you Mike! > > --- > 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 > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3379 Update text files for ypsiliform+2
On Tue, Feb 09, 2010 at 11:49:37AM +1300, Ralph Versteegen wrote: > >Is it too late to delay release? I found a rather large bug in music >importation. > >Ralph Yep, it too late to hold ypsiliform+2 But I see absolutely no good reason why we couldn't release +3 tomorrow :) What is the import bug? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3380 rectangle now takes both pages or frames
On Mon, Feb 08, 2010 at 08:18:40PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-08 20:18:40 -0800 (Mon, 08 Feb 2010) > 41 > rectangle now takes both pages or frames Wondering about the consequences of only resetting setclip in the page version not the frames version. Since the goal is to phase out setclip entirely, I think it is okay... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3380 rectangle now takes both pages or frames
On Tue, Feb 09, 2010 at 05:51:19PM +1300, Ralph Versteegen wrote: > On 9 February 2010 17:21, James Paige wrote: > > On Mon, Feb 08, 2010 at 08:18:40PM -0800, subvers...@hamsterrepublic.com > > wrote: > >> james > >> 2010-02-08 20:18:40 -0800 (Mon, 08 Feb 2010) > >> 41 > >> rectangle now takes both pages or frames > > > > Wondering about the consequences of only resetting setclip in the page > > version not the frames version. Since the goal is to phase out setclip > > entirely, I think it is okay... > > > > --- > > James > > That's not right. All functions that write to a frame MUST call > setclip, or they will crash when attempting to draw over the edge. Yeah... I screwed things up. I definitely should have tested better before checking those in. Fix (or revert) coming soon... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3383 Fix infinite loop/stack overflow crash in fuzzyrect (r3382), fix missing
On Mon, Feb 08, 2010 at 09:04:17PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-02-08 21:04:17 -0800 (Mon, 08 Feb 2010) > 142 > Fix infinite loop/stack overflow crash in fuzzyrect (r3382), fix missing > setclip calls in r3380-3382, and remove shrinkclip overload for pages Thank you! --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3375 Fix a broken null-pointer check in SliceLoadFromFile() which was causing
On Wed, Feb 10, 2010 at 04:37:48AM +1300, Ralph Versteegen wrote: > On 4 February 2010 04:45, wrote: > > james > > 2010-02-03 07:45:34 -0800 (Wed, 03 Feb 2010) > > 125 > > Fix a broken null-pointer check in SliceLoadFromFile() which was causing > > crashes when trying to load a nonexistant filename. > > --- > > U wip/slices.bas > > "slicetree_0.reld" is never lumped, because lumpfiles() skips over any > files with non-8.3 names. This limit should really be removed (though Oops! I didn't notice because I was only testing with an rpgdir. > I am hoping for a 32 bit DOS OHR port someday, the lumpfile > abstraction layer will mean that any OS filename limits won't be a > problem by then). Doesn't FreeDos support long filenames the Windows 95 way? But yes, lump abstraction==good > Anyway, I would just remove this limit, but I am > guessing that you did this on purpose, to prevent this from being > lumped? Nope, just carelessness. And that I forgot that I had not already removed the 8.3 lump name limit. :) > PS: most ridiculous use of an operating system: http://www.japheth.de/HX.html > Well, WxWidgets runs on DOS as well, using the 'universal' widget set, > but that seems... kind of reasonable? Hehe. Sounds like fun... for a certain value of "fun" ;) --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3375 Fix a broken null-pointer check in SliceLoadFromFile() which was causing
On Wed, Feb 10, 2010 at 06:40:46AM +1300, Ralph Versteegen wrote: > On 4 February 2010 04:48, James Paige wrote: > > On Wed, Feb 03, 2010 at 07:45:34AM -0800, subvers...@hamsterrepublic.com > > wrote: > >> james > >> 2010-02-03 07:45:34 -0800 (Wed, 03 Feb 2010) > >> 125 > >> Fix a broken null-pointer check in SliceLoadFromFile() which was causing > >> crashes when trying to load a nonexistant filename. > >> --- > > > > This bug makes me wonder if anybody other than myself has actually seen > > GridSlice and slice clipping in a action yet? > > > A very similar bug has appeared: this time, the slice editor always > crashes when leaving, when deleting the reload document after saving > the slice tree. I'm wondering why noone else has noticed it (it's been > frustrating me all evening, but I put off investigating it.) > > The problem is somewhere in FreeNode while updating the previous and > next siblings. Somehow the value of nod is being changed to > nod->nextsib (I think). After labourous stepping through in gdb, it > seems that suddenly everything goes crazy. I think it's probably > another nasty FB. Hmm... I don't see the crash at all... I wonder what is different for me? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3375 Fix a broken null-pointer check in SliceLoadFromFile() which was causing
On Wed, Feb 10, 2010 at 02:01:49PM +1300, Ralph Versteegen wrote: > On 10 February 2010 06:55, James Paige wrote: > > On Wed, Feb 10, 2010 at 06:40:46AM +1300, Ralph Versteegen wrote: > >> On 4 February 2010 04:48, James Paige wrote: > >> > On Wed, Feb 03, 2010 at 07:45:34AM -0800, subvers...@hamsterrepublic.com > >> > wrote: > >> >> james > >> >> 2010-02-03 07:45:34 -0800 (Wed, 03 Feb 2010) > >> >> 125 > >> >> Fix a broken null-pointer check in SliceLoadFromFile() which was causing > >> >> crashes when trying to load a nonexistant filename. > >> >> --- > >> > > >> > This bug makes me wonder if anybody other than myself has actually seen > >> > GridSlice and slice clipping in a action yet? > >> > > >> A very similar bug has appeared: this time, the slice editor always > >> crashes when leaving, when deleting the reload document after saving > >> the slice tree. I'm wondering why noone else has noticed it (it's been > >> frustrating me all evening, but I put off investigating it.) > >> > >> The problem is somewhere in FreeNode while updating the previous and > >> next siblings. Somehow the value of nod is being changed to > >> nod->nextsib (I think). After labourous stepping through in gdb, it > >> seems that suddenly everything goes crazy. I think it's probably > >> another nasty FB. > > > > Hmm... I don't see the crash at all... > > I wonder what is different for me? > > > > --- > > James > > I found the problem. It's my old friend, argument passing defaulting to BYREF! > > Actually, I'm concerned that you don't see the crash. However, when I > tried the editor a few days ago, I didn't see a crash either. > > It seems impossible for it not to crash: any time you free a RELOAD > node with at least 2 children, the pointers will get messed up which > will result in a double free, null pointer dereference, etc. It > crashes for me in both windows and linux. I'm using FB 0.20 in both > cases, what are you using? FB 0.20 on Linux (Ubuntu 9.04). I tested both with gdb and without. Still no crashes. Although I am glad you found and fixed the problem :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3397 Okay, frame_cropped_view was still all wrong. Think it is right now...
On Tue, Feb 09, 2010 at 10:47:27PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-09 22:47:27 -0800 (Tue, 09 Feb 2010) > 71 > Okay, frame_cropped_view was still all wrong. Think it is right now... I am working on fixing up edgebox to crop without ever calling setclip, but I am making a mess of things. I'll have to sort it out tomorrow. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3397 Okay, frame_cropped_view was still all wrong. Think it is right now...
On Wed, Feb 10, 2010 at 07:54:27PM +1300, Ralph Versteegen wrote: > On 10 February 2010 19:47, wrote: > > james > > 2010-02-09 22:47:27 -0800 (Tue, 09 Feb 2010) > > 71 > > Okay, frame_cropped_view was still all wrong. Think it is right now... > > --- > > U wip/allmodex.bas > > I guess you're set on changing slice clipping to using > sprite_new_view, by changing the whole slice system to uses frames > instead of pages? I've been meaning to reimplement slice clipping > since I mentioned it, but I was going to use pages, not frames. That > way clipping could be acheieve in just a few lines of code. I was planning to do slice clipping with slice_new_view, although if you see a way to do it better with pages, I am all ears. I am still feeling clumsy with both setclip and sprite_new_view --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3397 Okay, frame_cropped_view was still all wrong. Think it is right now...
On Wed, Feb 10, 2010 at 07:57:19PM +1300, Ralph Versteegen wrote: > On 10 February 2010 19:53, James Paige wrote: > > On Tue, Feb 09, 2010 at 10:47:27PM -0800, subvers...@hamsterrepublic.com > > wrote: > >> james > >> 2010-02-09 22:47:27 -0800 (Tue, 09 Feb 2010) > >> 71 > >> Okay, frame_cropped_view was still all wrong. Think it is right now... > > > > I am working on fixing up edgebox to crop without ever calling setclip, > > but I am making a mess of things. I'll have to sort it out tomorrow. > > > > --- > > James > > Why are you doing that? Just for the sake of getting rid of setclip? > Like I said before, I think getting rid of setclip is more trouble > than it's worth: rewriting edgebox not to use setclip will make it > extremely messy. setclip is safe as long as you only call it before > calling a primitive drawing function. Not for the sake of getting rid of setclip, just for the sake on not using it in edgebox. Then it seems to me that it would be possible to call setclip once before edgebox and have it work right... but of course that doesn't jive well with my previously stated plan doing slice drawing with views... Like I say, I am still feeling clumsy with this clipping stuff.. > Anyway, if you're stopping for today, then I'll do > slice-clipping-using-views right now. Yay! :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3402 Reimplement slice clipping using sprite_new_view.
On Wed, Feb 10, 2010 at 09:35:06AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-02-10 09:35:06 -0800 (Wed, 10 Feb 2010) > 310 > Reimplement slice clipping using sprite_new_view. > Grid child clipping isn't working. After investigating with gdb, it appears > that this is because the slice data shown in the editor and the actual data > are completely different! For example, when I set 3x3 cells nonclipping, it > was actually 1x0 cells clipping. I am getting a freeze in the slice editor when I load a slice collection that contains a cliping grid. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3402 Reimplement slice clipping using sprite_new_view.
On Wed, Feb 10, 2010 at 09:50:02AM -0800, James Paige wrote: > On Wed, Feb 10, 2010 at 09:35:06AM -0800, subvers...@hamsterrepublic.com > wrote: > > teeemcee > > 2010-02-10 09:35:06 -0800 (Wed, 10 Feb 2010) > > 310 > > Reimplement slice clipping using sprite_new_view. > > Grid child clipping isn't working. After investigating with gdb, it appears > > that this is because the slice data shown in the editor and the actual data > > are completely different! For example, when I set 3x3 cells nonclipping, it > > was actually 1x0 cells clipping. > > I am getting a freeze in the slice editor when I load a slice collection > that contains a cliping grid. Oops, not a freeze, just a long freezelike delay. Also looks like grid children are not doing the bottom and right padding correctly. Maybe related? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3403 Slice editor was not refreshing the menu after an import
On Wed, Feb 10, 2010 at 01:41:54PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-10 13:41:54 -0800 (Wed, 10 Feb 2010) > 57 > Slice editor was not refreshing the menu after an import It was this, and not the recent clipping changes that explains the freeze/delay symptoms I mentioned ealier. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3404 'Case insensitive' indeed. I broke lumping on linux
On Thu, Feb 11, 2010 at 08:15:33AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-02-11 08:15:33 -0800 (Thu, 11 Feb 2010) > 51 > 'Case insensitive' indeed. I broke lumping on linux ...And I failed to notice on account of still only testing with an unlumped rpgdir :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3406 Fix clipping for GridSlice children.
On Thu, Feb 11, 2010 at 09:04:39AM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-11 09:04:38 -0800 (Thu, 11 Feb 2010) > 293 > Fix clipping for GridSlice children. > Grid children were being clipped by the parent using the grandparents clipper > callback. > Actually, all slices were being clipped by the parent using the grandparent's > clipper, > but that only mattered for grids because they have the only non-default > clipper So incidentally, a grid inside a grid would have clipped correctly :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3406 Fix clipping for GridSlice children.
On Fri, Feb 12, 2010 at 06:12:58AM +1300, Ralph Versteegen wrote: > On 12 February 2010 06:10, James Paige wrote: > > On Thu, Feb 11, 2010 at 09:04:39AM -0800, subvers...@hamsterrepublic.com > > wrote: > >> james > >> 2010-02-11 09:04:38 -0800 (Thu, 11 Feb 2010) > >> 293 > >> Fix clipping for GridSlice children. > >> Grid children were being clipped by the parent using the grandparents > >> clipper callback. > >> Actually, all slices were being clipped by the parent using the > >> grandparent's clipper, > >> but that only mattered for grids because they have the only non-default > >> clipper > > > > So incidentally, a grid inside a grid would have clipped correctly :) > > > > But doesn't. I'm working on fixing clpping now (which let you beat me > to checking in the GridSlice fix!) Which proves that I didn't actually *test* a grid inside a grid :) --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3408 Fix slice clipping; nesting clipping, positioning, and clip rects partia
On Thu, Feb 11, 2010 at 10:44:45AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-02-11 10:44:45 -0800 (Thu, 11 Feb 2010) > 95 > Fix slice clipping; nesting clipping, positioning, and clip rects partially > offscreen now work. Slick! It looks great. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3408 Fix slice clipping; nesting clipping, positioning, and clip rects partia
On Fri, Feb 12, 2010 at 08:54:46AM +1300, Ralph Versteegen wrote: > On 12 February 2010 08:00, James Paige wrote: > > On Thu, Feb 11, 2010 at 10:44:45AM -0800, subvers...@hamsterrepublic.com > > wrote: > >> teeemcee > >> 2010-02-11 10:44:45 -0800 (Thu, 11 Feb 2010) > >> 95 > >> Fix slice clipping; nesting clipping, positioning, and clip rects > >> partially offscreen now work. > > > > Slick! It looks great. > > > > --- > > James > > When I said "a few lines of code" I expected far fewer than this; > getting this working properly was actually pretty difficult. Looking at the diff, I believe it :) > But all is not well. I saw this on CP: > "Problem is, the big sprite blips out (as far as I can tell) when it > wraps around the map, even using the nightly." > Hmm, maybe map layers will need their own RefreshChildren method which > contains the current (unreliable) framewalkabout logic. In that case a script is manually re-positioning the slice to match the position of an NPC once each frame. I am guessing this is causing an off-by-one sort of error when the NPC wraps, and it takes the slice one tick to catch up... actually, I wonder if the slice is lagging behind the NPC one tick all the time, and it only becomes noticeable when you wrap. > (However, I feel that using "move slice above/below (sl, lookup > slice(sl:map layer X))" makes more sense than parenting a slice to a > layer: for example, to display a slice above NPCs but below tree > tops.) I think that wouldn't make a difference in this case. > (Aside: I notice some grid slice glitches in the editor: repeatedly > parenting and deparenting a slice to a grid causes it to walk across > the screen.) I see. Actually, it looks like all reparenting is causing crazy slice motion, even when no grids are involved. The editor attempts to preserve a slice's old ScreenX and ScreenY when it changes parents. It seemed a good idea when I was first writing it, but I am not so sure now... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3410 When reparenting a slice into a grid in the editor, it makes more sense
On Thu, Feb 11, 2010 at 01:38:15PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-11 13:38:15 -0800 (Thu, 11 Feb 2010) > 115 > When reparenting a slice into a grid in the editor, it makes more sense to > reset the position that to preserve it. This also means you can easily use a temporary grid to arrange your slices, then reparent them out of the grid, and delete the grid. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3408 Fix slice clipping; nesting clipping, positioning, and clip rects partia
On Fri, Feb 12, 2010 at 06:58:29PM +1300, Ralph Versteegen wrote: > On 12 February 2010 10:04, James Paige wrote: > > On Fri, Feb 12, 2010 at 08:54:46AM +1300, Ralph Versteegen wrote: > >> On 12 February 2010 08:00, James Paige wrote: > >> > On Thu, Feb 11, 2010 at 10:44:45AM -0800, subvers...@hamsterrepublic.com > >> > wrote: > >> >> teeemcee > >> >> 2010-02-11 10:44:45 -0800 (Thu, 11 Feb 2010) > >> >> 95 > >> >> Fix slice clipping; nesting clipping, positioning, and clip rects > >> >> partially offscreen now work. > >> > > >> > Slick! It looks great. > >> > > >> > --- > >> > James > >> > >> When I said "a few lines of code" I expected far fewer than this; > >> getting this working properly was actually pretty difficult. > > > > Looking at the diff, I believe it :) > > > >> But all is not well. I saw this on CP: > >> "Problem is, the big sprite blips out (as far as I can tell) when it > >> wraps around the map, even using the nightly." > >> Hmm, maybe map layers will need their own RefreshChildren method which > >> contains the current (unreliable) framewalkabout logic. > > > > In that case a script is manually re-positioning the slice to match the > > position of an NPC once each frame. I am guessing this is causing an > > off-by-one sort of error when the NPC wraps, and it takes the slice one > > tick to catch up... actually, I wonder if the slice is lagging behind > > the NPC one tick all the time, and it only becomes noticeable when you > > wrap. > > No, I'm not talking about that script. I mean that NPCs wrap around > map edges, but slices parented to map layers don't. When we switch to > using slices for NPCs, rather than recalculating the on-screen > position of all NPC slices the way we currently do for NPCs, prehaps > we can generalise this to all slices attached to map slice objects... > which would include map layers, the NPC/heroes slice layer(s), and the > map root (in case movesliceabove/below is used). Ah, okay! I am on the trolley now! That is a good idea! --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3379 Update text files for ypsiliform+2
On Fri, Feb 12, 2010 at 07:21:13PM +1300, Ralph Versteegen wrote: > On 9 February 2010 12:04, James Paige wrote: > > On Tue, Feb 09, 2010 at 11:49:37AM +1300, Ralph Versteegen wrote: > >> > >> Is it too late to delay release? I found a rather large bug in music > >> importation. > >> > >> Ralph > > > > Yep, it too late to hold ypsiliform+2 > > But I see absolutely no good reason why we couldn't release +3 tomorrow > > :) > > > > What is the import bug? > > > > --- > > James > > Calling oggenc and madplay doesn't work when Custom's path contains > spaces. In addition, the fix for the SHELL call to oggenc/madplay > causing gfx_sdl to lose track of the state of the keyboard didn't work > either (recall that this happens on windows only, when not compiling > with -s console). GLOW reported that trying to import an mp3 file into > his game (his Custom's path contained all kinds of spaces, commas and > exclamation marks) caused the import to loop, walked through several > of his songs, and overwrote them with whatever ogg file was first in > the directory! > > On testing, I managed to see SHELL cause SDL to get confused just > once, but GLOW reported that it happens most of the time on his > computer. As a workaround, I got him to switch to gfx_fb. > > The way that Windows' system() (which is all that a call to SHELL on > windows is) handles spaces and quotes is braindead (seems to be a > holdover from the DOS 1.0 or whatever days, type "cmd /?" to read > about it) - its behaviour changes depending whether the last character > in the string is a quote, and much other insanity - but I figured out > how to fix it, the patch is attached (didn't wrap it in #ifdefs). > However, I didn't check it in because it doesn't fix the root problem, > which is that SHELL just doesn't work well enough. I want some > alternative to SHELL which runs asynchronously, returns program output > simply, optionally runs hidden without popping up a console on > Windows, and returns the program exit code. Since FB doesn't have > anything like this, I think we'll have wrap platform specific system > calls and build our own. Okay, that sounds agreeable... Maybe like a wrapper function that runs SHELL for Linux, but does some Windows API calls for Windows? For now we could at least detect spaces in the path and pop up a warning if we know the import is going to fail. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3411 Add "same slice" identity test, since (handle1 == handle2) can fail
On Sat, Feb 20, 2010 at 05:35:29PM +1300, Ralph Versteegen wrote: > On 20 February 2010 10:30, wrote: > > james > > 2010-02-19 13:30:52 -0800 (Fri, 19 Feb 2010) > > 91 > > Add "same slice" identity test, since (handle1 == handle2) can fail > > under some conditions. > > --- > > U wip/docs/plotdict.xml > > U wip/docs/plotdictionary.html > > U wip/plotscr.hsd > > U wip/whatsnew.txt > > U wip/yetmore.bas > > Which conditions are those? We effectively intern slice handles, so I > would have thought that would be impossible. Actually, I am not sure... Thinking about it more, perhaps a "same slice" identity test isn't really needed. Maybe there is just a bug in one of the commands which is causing duplicate handles to the same slice. I have a variable named "player" which gets assigned in a "create player" script. The player slice may be reparented and resorted, and its siblings both before and after may be added or removed. At various points I loop though all children of a "sprites" slice, running functions on each slice, and sometimes they do special case handling when sl == player or when sl <> player I noticed that sl == player was never returning true. Apparently the previously set "player" variable was still valid, and I could manipulate the slice with it, but when looping through the slices with "next sibling" I would get a different handle number for the same slice. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3411 Add "same slice" identity test, since (handle1 == handle2) can fail
On Sat, Feb 20, 2010 at 11:46:48PM +1300, Ralph Versteegen wrote: > On 20 February 2010 23:22, James Paige wrote: > > On Sat, Feb 20, 2010 at 05:35:29PM +1300, Ralph Versteegen wrote: > >> On 20 February 2010 10:30, wrote: > >> > james > >> > 2010-02-19 13:30:52 -0800 (Fri, 19 Feb 2010) > >> > 91 > >> > Add "same slice" identity test, since (handle1 == handle2) can fail > >> > under some conditions. > >> > --- > >> > U wip/docs/plotdict.xml > >> > U wip/docs/plotdictionary.html > >> > U wip/plotscr.hsd > >> > U wip/whatsnew.txt > >> > U wip/yetmore.bas > >> > >> Which conditions are those? We effectively intern slice handles, so I > >> would have thought that would be impossible. > > > > Actually, I am not sure... Thinking about it more, perhaps a "same > > slice" identity test isn't really needed. Maybe there is just a bug in > > one of the commands which is causing duplicate handles to the same > > slice. > > > > I have a variable named "player" which gets assigned in a "create > > player" script. The player slice may be reparented and resorted, and its > > siblings both before and after may be added or removed. At various > > points I loop though all children of a "sprites" slice, running > > functions on each slice, and sometimes they do special case handling > > when sl == player or when sl <> player > > > > I noticed that sl == player was never returning true. Apparently the > > previously set "player" variable was still valid, and I could manipulate > > the slice with it, but when looping through the slices with "next > > sibling" I would get a different handle number for the same slice. > > > > --- > > James > > Yes, that's definitely a bug, and same slice should be removed. > > I think I found the bug, in create_plotslice_handle. Try now. Perfecto! --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Instead-chain trouble
I created a simplified duplictae of your setup (attacks 71, 72 and 0) and I am able to reproduce the freeze. Investigating... --- James Paige On Wed, Feb 24, 2010 at 09:30:40PM -0800, Adam Perry wrote: >In the game I'm working on, I have some Doppelganger enemies that detect >your characters' job classes and shapeshift into that form. > >That's the idea, anyway. How it actually works: if the tag check fails, >the battle freezes. > >My attack chains are set up like this: > >71: Doppel-R1: If tag 17 = OFF then use attack 72 instead >72: Doppel-R2: If tag 18 = OFF then use attack 73 instead >73: Doppel-R3: If tag 19 = OFF then use attack 74 instead >74: Doppel-R4: If tag 20 = OFF then use attack 75 instead >75: Doppel-R5: If tag 21 = OFF then use attack 0 instead > >Attack 0 is just a regular attack. > >So if tag 17 is on, that means the red character is in the Warrior class. >Doppel-R1 is used in that case, and the Doppelganger successfully >transforms. In any other case, though, the battle freezes. > >I notice that the source has some debug lines surrounding instead-chains. >These aren't firing in my case; the debug is clean. > >My guess from a scan of the source is that the attack delays are screwing >things up. (How do attack delays work with instead-chains, anyway? Seems >like the attack should be decided before the delay is calculated.) See >line 2265 of bmod.bas. > >I'm pretty sure I've got the attack chains set up correctly. Any ideas? > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3414 Fix bug 816: Freeze on attack instead-chaining on multi-stage chains.
On Thu, Feb 25, 2010 at 10:12:03AM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-02-25 10:12:03 -0800 (Thu, 25 Feb 2010) > 281 > Fix bug 816: Freeze on attack instead-chaining on multi-stage chains. > On a successful chain with a delay, the bat.atk.id for the current attack > was not being cleared. This had no effect on normal chains or else chains, > but caused instead-chains to repeat themselves over and over. > --- Adam, I forced an early nightly build so you can test this fix out as soon as you like. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3415 Clarify the documentation for "replace char" "delete char" and "ascii fr
On Fri, Feb 26, 2010 at 01:50:16PM +1300, Ralph Versteegen wrote: > On 26 February 2010 08:32, wrote: > > james > > 2010-02-25 11:32:11 -0800 (Thu, 25 Feb 2010) > > 230 > > Clarify the documentation for "replace char" "delete char" and "ascii from > > string" > > to specify that the position is indexed starting with 1 and going to > > "string length" > > (as opposed to starting at 0 and going to string length -- 1) > > --- > > U wip/docs/plotdict.xml > > U wip/docs/plotdictionary.html > > So I suppose that when string indexing using array subscripts is > added, it'll disagree with the existing string commands. Since > everything else in the engine uses 0 to num - 1 indexing, it would be > really inconsistent to make array indexing different, and it would be > extremely inconsistent to make string indexing an exception. > > Actually, "ascii from string", "string length", and if strings are > mutable, "replace char" will all have replacements, so will be > obsolete. Guess we could add either a remove-from-array command and > overload it to act on strings, or python's "del foo[i]" to replace > "delete char". Yeah, I am a lot more confortable with 0-based indexing. I was writing some code using ascii from char and it was driving me crazy that it wouldn't work right. When I looked at the source code I realized about the 1-based index, which i what prompted me to update the docs. I see no problem with having the "real" strings do indexing differently from the old-style strings, as long as the difference is documented. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3415 Clarify the documentation for"replace char" "delete char" and "ascii fr
*checks* Oh, yes. you are right! It is right there at the top of the string section. I missed that before. But it is good to have it repeated for the individual commands since Hamster Whisper's context help only displays one command at a time. --- James On Fri, Feb 26, 2010 at 04:03:53PM +, Mike Caron wrote: > Just out of curiosity, is there not a clause in the string section that says > "strings are indexed starting from 1"? I recall writing something like that a > while ago... > --Original Message-- > From: James Paige > Sender: ohrrpgce-boun...@lists.motherhamster.org > To: ohrrpgce@lists.motherhamster.org > ReplyTo: ohrrpgce@lists.motherhamster.org > Subject: Re: [Ohrrpgce] SVN: james/3415 Clarify the documentation for"replace > char" "delete char" and "ascii fr > Sent: Feb 26, 2010 10:58 AM > > On Fri, Feb 26, 2010 at 01:50:16PM +1300, Ralph Versteegen wrote: > > On 26 February 2010 08:32, wrote: > > > james > > > 2010-02-25 11:32:11 -0800 (Thu, 25 Feb 2010) > > > 230 > > > Clarify the documentation for "replace char" "delete char" and "ascii > > > from string" > > > to specify that the position is indexed starting with 1 and going to > > > "string length" > > > (as opposed to starting at 0 and going to string length -- 1) > > > --- > > > U wip/docs/plotdict.xml > > > U wip/docs/plotdictionary.html > > > > So I suppose that when string indexing using array subscripts is > > added, it'll disagree with the existing string commands. Since > > everything else in the engine uses 0 to num - 1 indexing, it would be > > really inconsistent to make array indexing different, and it would be > > extremely inconsistent to make string indexing an exception. > > > > Actually, "ascii from string", "string length", and if strings are > > mutable, "replace char" will all have replacements, so will be > > obsolete. Guess we could add either a remove-from-array command and > > overload it to act on strings, or python's "del foo[i]" to replace > > "delete char". > > Yeah, I am a lot more confortable with 0-based indexing. I was writing > some code using ascii from char and it was driving me crazy that it > wouldn't work right. When I looked at the source code I realized about > the 1-based index, which i what prompted me to update the docs. > > I see no problem with having the "real" strings do indexing differently > from the old-style strings, as long as the difference is documented. > > --- > 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 > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] saved slice collections
I am continuing to think about saved slice collections. I think I would like to have multiple separately indexed groups of slice collections. For example, group 0 would be collections for the user to load with plotscripting. And maybe group 1 would be layouts for individual save games on the save/load screen. You would normally only need one of these in the group, but you could have more. And maybe group 2 would be layouts for save/load screens. You would normally have two of these, one for save and one for load. (but you could have more if you thought of a reason) And maybe group 3 would be layouts for the status screen. Again, you only need one, but you can have more if you want. And we would go on allocating groups of slice collections for different purposes as we ensliceify various screens. And soon I think I will start work on an EmbedSlice which is a container for another slice collection. The slice collection editor (which I am going to get around to officially renaming one of these days) would not be able to *directly* edit the children of an EmbedSlice, but it will be able to jump into a sub-editor for an embed slice, (which will be exactly like the regular editor but with the root slice constrained in size) I am also wondering how commands that search the slice tree should handle EmbedSlice. Should they search its children just like with a ContainerSlice? Or should tree searches stop on EmbedSlices, and expect the scripter to do another search rooted at or below the embed if they want to search inside it. (I am leaning towards the latter, but I value input on the subject) --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3419 oobcure is now a wrapper around inflict instead of re-implementing the d
On Tue, Mar 02, 2010 at 11:09:54AM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-03-02 11:09:54 -0800 (Tue, 02 Mar 2010) > 256 > oobcure is now a wrapper around inflict instead of re-implementing the damage > calculations. > This resolves bug 819 (% damage outside battle) and bug 749 (no damage still > damages outside battle) > And could possibly resolve some other outside-battle problems. I tested this in a variety of ways, including items that permanently increase your max stats, and everything seems okay. Still, this totally changes the code-path for every single outside-battle item and outside-battle spell, so be on the lookout for potential unintended side-effects in existing games. I'll fix them if you find them ;) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3421 Outside battle attacks shouldn't be allowed to miss.
On Tue, Mar 02, 2010 at 01:05:15PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-03-02 13:05:15 -0800 (Tue, 02 Mar 2010) > 53 > Outside battle attacks shouldn't be allowed to miss. We might want a bitset to allow outside battle attacks to miss... --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3422 Bell of Chaos (work in progress)
On Wed, Mar 03, 2010 at 01:49:08PM -0800, subvers...@hamsterrepublic.com wrote: > james > 2010-03-03 13:49:08 -0800 (Wed, 03 Mar 2010) > 33 > Bell of Chaos (work in progress) Not offically releasing a demo until Friday, but subversion users are welcome to peek early >:) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3422 Bell of Chaos (work in progress)
> -The graphics are *fantastic*! Thanks! I am glad they are okay. I studied the maptiles from NES Faxanadu a lot, and googled a lot of Assyrian statuary. The pixeling is frustratingly time consuming. > -When I first played, I didn't know that you could pick up the bell, > because you have to stand at the highest point beneath it to be able > reach it. Maybe lower it? I was pretty confused at the point where I > was told to throw the bell to jump higher. > -The dialogue with the half sister by the bell icon triggers over and > over again; I was nearly stuck. > -I struggled to work out what the controls were; I didn't notice the > help menus, just like I didn't immediately notice them in Baconthulhu > and/or Don't Eat Soap. Of course, I didn't have the bell anyway. All excellent points! Thanks for the playtesting! > -I see you've already provided default demigoddess names Yeah. I think it is cool to be able to name her, but I found that when testing I was often wanting to ENTER right through that part to get to the game quicker. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3428 Replaced all use of __FB_LINUX__ with a new define, __UNIX__ (bad name?)
Does this change fix anything? --- James On Sat, Mar 06, 2010 at 12:44:30PM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-03-06 12:44:30 -0800 (Sat, 06 Mar 2010) > 280 > Replaced all use of __FB_LINUX__ with a new define, __UNIX__ (bad name?). > What a funny habit Linux programmers have. > > That's not to say that FB is the same on all unixes. Actually it has a lot of > linux-specific code, and all other unixes have identical, incomplete, library > code. > --- > U wip/allmodex.bas > U wip/browse.bas > U wip/common.bas > U wip/compat.bas > U wip/compat.bi > U wip/const.bi > U wip/custom.bas > U wip/game.bas > U wip/mapsubs.bas > U wip/music_native.bas > U wip/music_native2.bas > U wip/relump.bas > U wip/unlump.bas > U wip/util.bas > ___ > Ohrrpgce mailing list > ohrrpgce@lists.motherhamster.org > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3429 A couple workarounds for FB bugs, to enable compiling on FreeBSD. compat
On Mon, Mar 08, 2010 at 01:46:52AM -0800, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-03-08 01:46:52 -0800 (Mon, 08 Mar 2010) > 171 > A couple workarounds for FB bugs, to enable compiling on FreeBSD. compat.bi > should now usually be the first file included in each source file, but it > doesn't often matter. Aha! FreeBSD support! So that is what you are up to :) --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3428 Replaced all use of __FB_LINUX__ with a new define, __UNIX__ (bad name?)
On Mon, Mar 08, 2010 at 10:50:19PM +1300, Ralph Versteegen wrote: > We now support FreeBSD! I'm not planning to test any other unixes > aside from Darwin (tomorrow) and Mac OS X (day after) That sounds delicious! I assume it will be intel-macs only, but since that is most of them these days; Yay! --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3441 HWhisper: Switch to gtksourceview for syntax highlighting and parenthesi
On Fri, Mar 19, 2010 at 10:09:06PM -0700, subvers...@hamsterrepublic.com wrote: > james > 2010-03-19 22:09:06 -0700 (Fri, 19 Mar 2010) > 83 > HWhisper: Switch to gtksourceview for syntax highlighting and parenthesis > matching This works really nice, but so far I have only tested it on Linux, and I have not yet investigated how to make sure that py2exe bundles all the required gtksourceview support files into the exe. --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] power outage
In case anybody was wondering, the wiki and subversion are down right now because of a power outage, expected to be remedied by tomorrow morning. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
[Ohrrpgce] Feature idea: game distribution menu
I was thinking about game distribution, and an idea occured to me. We could have a menu in custom that would allow the game author to easily prepare their game for distribution. The menu could include options like: Edit README file Package in Zip file Package as Windows installer The README editor could just edit a text file. A copy of it could be stored inside the RPG file. We could provide a generic README template for people to customize "Package as a zip file" would call out to an external zip.exe program and would bundle your RPG file, a renamed copy of game.exe, a copy of your README and a copy of LICENSE-binary.txt "Package as a Windows installer" would work similarly, except that it would call out to Innosetup or NSIS or something like that. And if TMC's experiments with a Mac OS X binary work out, we could eventually have a "Package as a Mac App Bundle" too. A "Package as a Linux .deb file" option would be plausible too. We can't redistribute all the tools necessary to do all this packaging, but we could certainly detect and use such tools if they were present. Any thoughts on this idea? --- James Paige ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] Feature idea: game distribution menu
On Thu, Mar 25, 2010 at 01:43:02PM -0700, Adam Perry wrote: >On Thu, Mar 25, 2010 at 1:29 PM, James Paige >wrote: > > Any thoughts on this idea? > >You know, when I read the subject line, my first thought was a menu that >automatically pulls games from the web (i.e. it allows authors to >distribute their games in a way that's directly connected to the engine). >*That* would be cool :) That is a possiibility too, although I always thought that job would be best done by a separate frontend program. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3452 Add "set slice clipping" and "get slice clipping"
On Fri, Apr 02, 2010 at 07:59:37AM -0700, subvers...@hamsterrepublic.com wrote: > james > 2010-04-02 07:59:37 -0700 (Fri, 02 Apr 2010) > 142 > Add "set slice clipping" and "get slice clipping" > (Warning! there is a problem with these! That is why they aren't in the > documentation yet!) The actuall commands work fine, but the problem is that simething crazy is happening with the clipping behavior in slicetest.rpg If you run slicetest.rpg you will see a 80x80 sprite loaded inside a 50x50 container. The container is set to clip, and the sprite gets moved around. But the sprite only gets clipped on the top and left edges. The bottom and right of the sprite are unclipped. If you load slicetest.rpg and go into the slice collection editor, you will see the same setup. An 80x80 sprite clipped inside a 50x50 container. In the slice collection editor, the sprite is clipped correctly on all sides. I can't figure out what the heck is going on :( --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3452 Add "set slice clipping" and "get slice clipping"
On Sat, Apr 03, 2010 at 04:44:14AM +1300, Ralph Versteegen wrote:
> On 3 April 2010 04:04, James Paige wrote:
> > On Fri, Apr 02, 2010 at 07:59:37AM -0700, subvers...@hamsterrepublic.com
> > wrote:
> >> james
> >> 2010-04-02 07:59:37 -0700 (Fri, 02 Apr 2010)
> >> 142
> >> Add "set slice clipping" and "get slice clipping"
> >> (Warning! there is a problem with these! That is why they aren't in the
> >> documentation yet!)
> >
> > The actuall commands work fine, but the problem is that simething crazy
> > is happening with the clipping behavior in slicetest.rpg
> >
> > If you run slicetest.rpg you will see a 80x80 sprite loaded inside a
> > 50x50 container. The container is set to clip, and the sprite gets moved
> > around. But the sprite only gets clipped on the top and left edges. The
> > bottom and right of the sprite are unclipped.
> >
> > If you load slicetest.rpg and go into the slice collection editor, you
> > will see the same setup. An 80x80 sprite clipped inside a 50x50
> > container. In the slice collection editor, the sprite is clipped
> > correctly on all sides.
> >
> > I can't figure out what the heck is going on :(
> >
> > ---
> > James
>
> We need...
>
> ...in-game debugging of the slice tree, using the slice collection
> editor!! ()
!!! () [!!!] {!}
That is a great idea!
---
James
___
Ohrrpgce mailing list
ohrrpgce@lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3454 Fix frame clipping bug: now that you can specify any frame as a destinat
On Fri, Apr 02, 2010 at 09:46:43AM -0700, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-04-02 09:46:43 -0700 (Fri, 02 Apr 2010) > 160 > Fix frame clipping bug: now that you can specify any frame as a destination > rather than just video pages, clippedsprite needs to be updated not just in > freepage Yay! Awesome! Also, for some reason this reminds me. Try taking a screenshot of a hero's status screen with F12. Instead you get what is behind the status screen. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: pkmnfrk/3463 Fixing ReadVLI and WriteVLI, as well as a few other minor things.
On Mon, Apr 05, 2010 at 10:14:19PM -0700, subvers...@hamsterrepublic.com wrote: > pkmnfrk > 2010-04-05 22:14:19 -0700 (Mon, 05 Apr 2010) > 223 > Fixing ReadVLI and WriteVLI, as well as a few other minor things. > > Specifically, since WriteVLI writes bits out low->high, that's the order > ReadVLI will now read them in! (They were completely broken before, I > appologise!) > --- > U wip/reload.bas Yay! Thank you for fixing this! :) I like Reload. I'll be using it for the new save format pretty soon. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: pkmnfrk/3463 Fixing ReadVLI and WriteVLI, as well as a few other minor things.
I think I can do everything I need to do with the format without RPath. Could you add an explanation of VLI to the wiki page about RELOAD? Earlier today I was reading it, and I was thinking "VLI? Very Long Int?" I didn't remember that it meant Variable Length Int, and I certainly didn;t remember how it whosit with the bits and whatit with the other bits by gum sonny! --- James On Tue, Apr 06, 2010 at 05:41:34AM +, Mike Caron wrote: > No problem. I may still work on the RPath stuff, some day. Maybe ;) > --Original Message-- > From: James Paige > Sender: ohrrpgce-boun...@lists.motherhamster.org > To: ohrrpgce@lists.motherhamster.org > ReplyTo: ohrrpgce@lists.motherhamster.org > Subject: Re: [Ohrrpgce] SVN: pkmnfrk/3463 Fixing ReadVLI and WriteVLI,as well > as a few other minor things. > Sent: Apr 6, 2010 1:37 AM > > On Mon, Apr 05, 2010 at 10:14:19PM -0700, subvers...@hamsterrepublic.com > wrote: > > pkmnfrk > > 2010-04-05 22:14:19 -0700 (Mon, 05 Apr 2010) > > 223 > > Fixing ReadVLI and WriteVLI, as well as a few other minor things. > > > > Specifically, since WriteVLI writes bits out low->high, that's the order > > ReadVLI will now read them in! (They were completely broken before, I > > appologise!) > > --- > > U wip/reload.bas > > Yay! Thank you for fixing this! :) > > I like Reload. I'll be using it for the new save format pretty soon. > > --- > 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 > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3465 Fix a comment I was previously confusedabout regarding rliNull
Although unless you do version 2 really soon, we will have to keep version 1 reading support included for old data. Personally, I wouldn't bother with unification for the sake of unification, and would postpone the changes until there is some additional impetus for a version 2 of reload. --- James On Tue, Apr 06, 2010 at 04:06:50PM +, Mike Caron wrote: > In retrospect, having two sets of data types was probably a stupid idea. > > The rli* constants are the physical on-disk format (byte, short, etc). The > rlt* constants are the logical, in memory format (integer, string, etc) > > Perhaps in V2 of RELOAD, I will unify the two formats. I should have used VLI > for the integer type, and something like it for the floating-point type. > > Fortunately, I had the foresight to include versioning, so this transition > should be painless... > --Original Message-- > From: subvers...@hamsterrepublic.com > Sender: ohrrpgce-boun...@lists.motherhamster.org > To: ohrrpgce@lists.motherhamster.org > ReplyTo: ohrrpgce@lists.motherhamster.org > Subject: [Ohrrpgce] SVN: james/3465 Fix a comment I was previously > confusedabout regarding rliNull > Sent: Apr 6, 2010 10:01 AM > > james > 2010-04-06 07:01:40 -0700 (Tue, 06 Apr 2010) > 64 > Fix a comment I was previously confused about regarding rliNull > --- > U wip/reload.bas > ___ > 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 > > ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3466 Wrote a proper lexer for HSpeak - nearly: it still produces strings rath
On Tue, Apr 06, 2010 at 12:34:19PM -0700, subvers...@hamsterrepublic.com wrote: > teeemcee > 2010-04-06 12:34:18 -0700 (Tue, 06 Apr 2010) > 596 > Wrote a proper lexer for HSpeak - nearly: it still produces strings rather > than lexemes since the rest of HSpeak wouldn't know what to do with them. > > ", $, and = are no longer valid characters in identifiers. Unfortunately this > was not warned about, although I could have told you this was going to > happen. HSpeak disallows any use of $, =, or strings outside of plotstrings > and script arguments. > > This is required for script error line number reporting for a very > round-about reason. More importantly, it is a big step towards HS4. > > As a bonus, the new lexer is 4 times faster than the old one. > --- > U wip/hspeak.exw > U wip/hsspiffy.e > U wip/whatsnew.txt Nice! As for restricting " $ and = in symbols, it was dumb of me to have ever allowed those in the first place. --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: james/3462 Add descriptive debugs to all the failure conditions in Reload.LoadDocum
On Wed, Apr 07, 2010 at 07:37:39AM +1200, Ralph Versteegen wrote: > On 6 April 2010 16:52, Mike Caron wrote: > > Just FYI, as well, the panic message probably shouldn't be followed by "END > > 1". A Return NULL should suffice... > > > > I'm still working on cracking this nut, though... > > > > subvers...@hamsterrepublic.com wrote: > >> > >> james > >> 2010-04-05 21:51:09 -0700 (Mon, 05 Apr 2010) > >> 141 > >> Add descriptive debugs to all the failure conditions in > >> Reload.LoadDocument and Reload.SerializeBin. > >> Flandersize the "OHFUCK" error message. > >> --- > >> U wip/reload.bas > > > > -- > > Mike > > It would be good to have error throwing with error levels. I felt a > little bit daunted by the task, but it's sorely lacking; I better get > around to it sometime... unless someone else wants to. What is involved? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: pkmnfrk/3468 Reworking reloadtest.bas into a unit test of the key features of RELOAD
On Tue, Apr 06, 2010 at 06:03:29PM -0700, subvers...@hamsterrepublic.com wrote: > pkmnfrk > 2010-04-06 18:03:29 -0700 (Tue, 06 Apr 2010) > 411 > Reworking reloadtest.bas into a unit test of the key features of RELOAD > (creating documents, navigating documents, serializing and deserializing > trees, etc). > > Also, minor optimization in the Node type, by sticking ->num and ->flo in a > Union together, since only one of those is valid at any given time (depending > on ->nodeType). I would have stuck ->str in there too, but for some reason, > FB doesn't like that. > --- > U wip/reload.bi > U wip/reloadtest.bas This is great, thank you! --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Re: [Ohrrpgce] SVN: teeemcee/3466 Wrote a proper lexer for HSpeak - nearly: it still produces strings rath
On Wed, Apr 07, 2010 at 08:58:39PM +1200, Ralph Versteegen wrote: > On 07/04/2010, Seth Hetu wrote: > >> Wrote a proper lexer for HSpeak - nearly: it still produces strings rather > >> than lexemes since the rest of HSpeak wouldn't know what to do with them. > > > > Congratulations! May I ask what kind of lexer it is? (Recursive > > descent, I'm guessing). > > > > -->Seth > > I thought recursive descent was used only for parsers, not lexers (but > maybe complicated context sensitive grammars would require them)? > > I looked around for parser generators for Euphoria and found one, but > it had an infexible lexer, so after considering writing my own lexer > generator I simply hand coded it - just as well, turned out to not be > much work. The lexer doesn't distinguish numbers yet, but I think I > shall add that, because I think I shall upgrade HSpeak to use tokens > rather than strings (which will be a huge change requiring a lot of > rewriting) You know the hspeak code better than I, would it be worth it to try and move away from euphoria entirely? --- James ___ Ohrrpgce mailing list ohrrpgce@lists.motherhamster.org http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
