headers
Ralph Versteegen | 1 Jul 2009 02:37
Picon

Re: SVN: teeemcee/2759 Split up and cleaned up (visually and code) the General Game Data menu,

2009/7/1 James Paige <Bob <at> hamsterrepublic.com>:
> On Tue, Jun 30, 2009 at 06:48:58AM -0700, subversion <at> HamsterRepublic.com wrote:
>> teeemcee
>> 2009-06-30 06:48:58 -0700 (Tue, 30 Jun 2009)
>> 431
>> Split up and cleaned up (visually and code) the General Game Data menu, and rearranged the Graphics menu.
Stat caps and new game options aare now on new menus.
>> Committing with one known bug: number of inventory rows reporting is off, because last_inv_slot is
screwed up. I can't even figure out what that function is meant to return.
>
> Nifty! This looks much nicer now :)
>
>> Poll: should Title, Battle and Victory music options be moved to the Special Sound Effects Menu?
>
> I vote yes, and rename it "Global Music & Sound Effects"
>
> I also really want the special plotscripts to appear in the script
> management menu (although that does not mean they need to be removed
> from the General Game Data menu)

Thinking alike there.

> I'll check out the inventory row display.
>
> What it is *supposed* to do is round up to the next full row of 3, but
> looking at the code, I can see it does not actually do that.

Aha. So that means that you can't actually set the number of inventory
slots, only the number of inventory rows? Quite a misleading menu
option then: if that's the case, we should only let users increment
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 1 Jul 2009 04:54
Picon

Slice at pixel

I just sat down to add 'slice at pixel' and 'child slice at pixel'
commands or something similar to that (that's right, yet another
distraction), which would work like npcatpixel, searching all the
descendants of a slice. But when I looked at the slices code, I
remembered that I don't understand it very well. Specifically:

ScreenX, ScreenY, Width and Height define the collision bounaries, not
the real boundaries? Thinking about this more, maybe I should also
provide something like 'slice collide at pixel' which looks for a
pixel within a slice's collision boundaries, while slice at pixel
checks the real boundaries? But if everything else uses the collision
boundaries, then maybe it would be best if 'slice at pixel' used them
too...

The plotdict entry for 'slice x' states that "This position is
relative to the slice's parent, and may depend upon the slice's Align
settings." (Compare slice screen x, "This position is relative to the
screen, so it is calculated based on not only the slice's X position,
but also its alignment, and the position and size of its parents.")
But slicescreenx returns 'sl->ScreenX + SliceXAnchor(sl)' while slicex
returns just the X member. Is this an error in the dictionary?

RefreshSliceScreenPos recursively calls RefreshSliceScreenPos on the
'draw attach parent' of the slice, but DrawSlice does not update the
attach parent position. .attach isn't really used much at the moment,
but I assume that this is just because slices are incomplete. Is this
an error/unimplemented feature, or is/will it known that the 'attach
parent' will always be processed by DrawSlice first? I wouldn't want
sliceatpixel to call RefreshSliceScreenPos on every slice if it
doesn't have to.
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Paige | 1 Jul 2009 17:58
Favicon

gilgamesh is down

The building in which the gilgamesh server is located had a massive 
power failure last night. The wiki and the subversion repository are 
currently down. Hopefully they will be back up sometime today.

---
James
Permalink | Reply | 0 comments |
headers
James Paige | 1 Jul 2009 18:13
Favicon

Re: Slice at pixel

On Wed, Jul 01, 2009 at 02:54:21PM +1200, Ralph Versteegen wrote:
> I just sat down to add 'slice at pixel' and 'child slice at pixel'
> commands or something similar to that (that's right, yet another

I am guessing that slice at pixel would return the first slice found at 
a given screen x/y position, yes?
But what would child slice at pixel do?

> distraction), which would work like npcatpixel, searching all the
> descendants of a slice. But when I looked at the slices code, I
> remembered that I don't understand it very well. Specifically:
>
> ScreenX, ScreenY, Width and Height define the collision bounaries, not
> the real boundaries?

X and Y are the position relative to the parent. Width and Height are 
the boundaries. ScreenX and ScreenY are the cached screen position, 
which is calculated at draw time based on parent position (grandparent 
position, etc.)

> Thinking about this more, maybe I should also
> provide something like 'slice collide at pixel' which looks for a
> pixel within a slice's collision boundaries, while slice at pixel
> checks the real boundaries?

I am confused. What do you mean by "collision boundaries" vs "real 
boundaries?" All slices have a width and a height, and those are the 
slice's only boundaries.

> But if everything else uses the collision
(Continue reading)

Permalink | Reply | 4 comments |
headers
Mike Caron | 1 Jul 2009 18:20
Picon
Gravatar

Re: Slice at pixel

James Paige wrote:
> On Wed, Jul 01, 2009 at 02:54:21PM +1200, Ralph Versteegen wrote:
>> I just sat down to add 'slice at pixel' and 'child slice at pixel'
>> commands or something similar to that (that's right, yet another
> 
> I am guessing that slice at pixel would return the first slice found at 
> a given screen x/y position, yes?
> But what would child slice at pixel do?
> 
>> distraction), which would work like npcatpixel, searching all the
>> descendants of a slice. But when I looked at the slices code, I
>> remembered that I don't understand it very well. Specifically:
>>
>> ScreenX, ScreenY, Width and Height define the collision bounaries, not
>> the real boundaries?
> 
> X and Y are the position relative to the parent. Width and Height are 
> the boundaries. ScreenX and ScreenY are the cached screen position, 
> which is calculated at draw time based on parent position (grandparent 
> position, etc.)
> 
>> Thinking about this more, maybe I should also
>> provide something like 'slice collide at pixel' which looks for a
>> pixel within a slice's collision boundaries, while slice at pixel
>> checks the real boundaries?
> 
> I am confused. What do you mean by "collision boundaries" vs "real 
> boundaries?" All slices have a width and a height, and those are the 
> slice's only boundaries.
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
subversion | 3 Jul 2009 03:28
Favicon

SVN: james/2761 Nine holes of Mini-golf

james
2009-07-02 18:28:07 -0700 (Thu, 02 Jul 2009)
24
Nine holes of Mini-golf
---
U   games/wander/wander.rpgdir/wander.l16
U   games/wander/wander.rpgdir/wander.p16
U   games/wander/wander.rpgdir/wander.t16
U   games/wander/wander.rpgdir/wander.til
Permalink | Reply | 0 comments |
headers
subversion | 3 Jul 2009 09:47
Favicon

SVN: teeemcee/2762 Add a global (custom+game) statnames array instead of calls to readgloba

teeemcee
2009-07-03 00:47:31 -0700 (Fri, 03 Jul 2009)
168
Add a global (custom+game) statnames array instead of calls to readglobalstring. While I was at it, I
decided to add future support for more stats to the attack editor.
---
U   wip/common.bas
U   wip/common.bi
U   wip/const.bi
U   wip/custom.bas
U   wip/customsubs.bas
U   wip/flexmenu.bas
U   wip/game.bas
U   wip/menus.bas
U   wip/menustuf.bas
U   wip/subs2.bas
U   wip/yetmore.bas
Permalink | Reply | 0 comments |
headers
subversion | 3 Jul 2009 13:21
Favicon

SVN: teeemcee/2763 "Special Sound Effects" -> "Global Music and Sound Effects"

teeemcee
2009-07-03 04:21:26 -0700 (Fri, 03 Jul 2009)
133
"Special Sound Effects" -> "Global Music and Sound Effects"
Also, only let users increment the number of inventory slots in lots of 3
---
U   wip/menus.bas
Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 3 Jul 2009 13:35
Picon

Re: Slice at pixel

2009/7/2 Mike Caron <caron.mike <at> gmail.com>:
> James Paige wrote:
>>
>> On Wed, Jul 01, 2009 at 02:54:21PM +1200, Ralph Versteegen wrote:
>>>
>>> I just sat down to add 'slice at pixel' and 'child slice at pixel'
>>> commands or something similar to that (that's right, yet another
>>
>> I am guessing that slice at pixel would return the first slice found at a
>> given screen x/y position, yes?
>> But what would child slice at pixel do?
>>
>>> distraction), which would work like npcatpixel, searching all the
>>> descendants of a slice. But when I looked at the slices code, I
>>> remembered that I don't understand it very well. Specifically:
>>>
>>> ScreenX, ScreenY, Width and Height define the collision bounaries, not
>>> the real boundaries?
>>
>> X and Y are the position relative to the parent. Width and Height are the
>> boundaries. ScreenX and ScreenY are the cached screen position, which is
>> calculated at draw time based on parent position (grandparent position,
>> etc.)
>>
>>> Thinking about this more, maybe I should also
>>> provide something like 'slice collide at pixel' which looks for a
>>> pixel within a slice's collision boundaries, while slice at pixel
>>> checks the real boundaries?
>>
>> I am confused. What do you mean by "collision boundaries" vs "real
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralph Versteegen | 3 Jul 2009 14:35
Picon

Re: Slice at pixel

2009/7/2 James Paige <Bob <at> hamsterrepublic.com>:
> On Wed, Jul 01, 2009 at 02:54:21PM +1200, Ralph Versteegen wrote:
>> I just sat down to add 'slice at pixel' and 'child slice at pixel'
>> commands or something similar to that (that's right, yet another
>
> I am guessing that slice at pixel would return the first slice found at
> a given screen x/y position, yes?
> But what would child slice at pixel do?

The idea was that one would look for all slices descended from a
single slice (such as root as sprite layer), while the other would
look only at the children of a certain slice. For example, if you have
lots of enemy slices on a map, each with child slices for weapon,
shield, etc, and you just want to know whether you've hit an enemy or
not, you would just check the children of your enemies' container
slice.

Both would work like npc at spot or npc at pixel: they can return all
of the slices found at that pixel.

>> distraction), which would work like npcatpixel, searching all the
>> descendants of a slice. But when I looked at the slices code, I
>> remembered that I don't understand it very well. Specifically:
>>
>> ScreenX, ScreenY, Width and Height define the collision bounaries, not
>> the real boundaries?
>
> X and Y are the position relative to the parent. Width and Height are
> the boundaries. ScreenX and ScreenY are the cached screen position,
> which is calculated at draw time based on parent position (grandparent
(Continue reading)

Permalink | Reply | 1 comment |

Gmane