headers
Bob-bugzilla | 1 Feb 2007 01:03
Favicon

[Bug 294] 16-bit+ colors for Backdrops

http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=294

------- Comment #1 from neota <at> softhome.net  2007-01-31 16:03 -------
I would like this myself -- mainly because it would allow me to easily use a
different 256 color palette for each backdrop. -- then I think a better
solution would be to define a default palette for each BG (selecting between
the available master-palettes). Then a scheme would need to be worked out where
you could override the master-palette used for the upcoming battle BG. Mixing
the battleBG palette (sorted by intensity) with the master palette used for
sprites (also sorted by intensity), at 40% opacity, could provide an easy
atmospheric effect for sprites.

I must also make it clear that you can make pictures conformant to a particular
palette while using most paint tools. Blur is the only one that may cause major
trouble. 

--

-- 
Configure bugmail: http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
Permalink | Reply | 0 comments |
headers
subversion | 1 Feb 2007 04:19
Favicon

SVN: teeemcee/987 Added "none" option to map and battle music, previous "none" renamed to

teeemcee
2007-01-31 19:19:50 -0800 (Wed, 31 Jan 2007)
852
Added "none" option to map and battle music, previous "none" renamed to "silence"

A map with music set to none continues after a battle to play the music that it was playing before the battle,
this seemed the most logical. Victory music is also ignored. After a textbox with music with "reset music"
set to off, a map with 'none' music reverts to its old tune, just like a regular map. I'm not 100% about these behaviours.

Made a small improvements to zintgrabber and added a little documentation

Renamed stopsong in allmodex.bas to pausesong (which is what it really does), and added a wrapper stopsong
to GAME, which updates presentsong. changed instances of pausesong in CUSTOM and common.bas to pausesong.

Because of that change, fixed a bug where currentsong didn't return -1 when music wasn't playing - also
added this fact to the dictionary.
---
U   wip/allmodex.bas
U   wip/allmodex.bi
U   wip/bmod.bas
U   wip/common.bas
U   wip/docs/plotdict.xml
U   wip/game.bas
U   wip/mapsubs.bas
U   wip/menus.bas
U   wip/subs.bas
U   wip/whatsnew.txt
U   wip/yetmore.bas
U   wip/yetmore.bi
U   wip/yetmore2.bas
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob-bugzilla | 1 Feb 2007 23:15
Favicon

[Bug 295] New: 'Cut Sprite' Option in the Sprite-Drawing Screen

http://gilgamesh.hamsterrepublic.com/cgi-bin/bugzilla/show_bug.cgi?id=295

           Summary: 'Cut Sprite' Option in the Sprite-Drawing Screen
           Product: OHRRPGCE
           Version: unknown
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: feature request
          Priority: P3
         Component: CUSTOM.EXE (Usability)
        AssignedTo: ohrrpgce <at> lists.motherhamster.org
        ReportedBy: KizulEmeraldfire <at> gmail.com

This feature would be similar to the Cut Tiles option under Edit Maptiles ->
{tileset}.

Picture this: you have a sprite sheet, complete with a 4-bit, 16-color palette
filled with sprites, but you don't want to mess with splitting all these
sprites you made into seperate 20×20-pixel BMPs.
Basically, this option would allow you to go into the Sprite Editor (we'll use
Walkabout Sprites as an example), select a frame, press the 'X' key (or a
conveniently-placed 'CUT SPRITE' button), locate your sprite sheet BMP (or
choose to rip the sprites from a 256-color Backdrop; it'd skip over the 16-bit+
BDs), then just move the little square to the sprite you're wanting, et voilá!
Sprite imported and ready for using! Of course, like with the Import Sprite
screen, you'd still choose whether to overwrite the current palette or import
with a blank one.
The arrow keys/mouse would move the box one pixel; holding Alt plus one of the
arrow keys would make it move one spritesworth of pixels (32×40 for Heroes,
(Continue reading)

Permalink | Reply | 0 comments |
headers
caron.mike | 2 Feb 2007 01:24
Picon
Gravatar

OHRDev Blog has been updated!

OHRDev Blog has posted a new item, 'An Open Letter'

You may view the latest post at
http://ohrdev.com/2007/02/01/an-open-letter/
You received this e-mail because you asked to be notified when new updates are posted.
If you no longer wish to receive notifications of new posts then please visit:
http://ohrdev.com/subscribe.php
Best regards,

caron.mike <at> gmail.com
Permalink | Reply | 5 comments |
headers
caron.mike | 2 Feb 2007 04:36
Picon
Gravatar

OHRDev Blog has been updated!

OHRDev Blog has posted a new item, 'Test'

You may view the latest post at
http://ohrdev.com/2007/02/01/test/
You received this e-mail because you asked to be notified when new updates are posted.
If you no longer wish to receive notifications of new posts then please visit:
http://ohrdev.com/subscribe.php
Best regards,

caron.mike <at> gmail.com
Permalink | Reply | 0 comments |
headers
Keith Gable | 2 Feb 2007 04:48
Gravatar

Re: OHRDev Blog has been updated!

I got a copy of this, so the mailing list is working.

Anyway. There are a few valid reasons for doing that. If there were
some way to do it pragmatically, like say it's kept in
$PACKAGE_NAME-$PACKAGE_VERSION/, then okay. What does piss me off the
most is when it's
$PACKAGE_NAME-$SOMETHING_THAT_I_HAVE_TO_CHANGE_LIKE_A_CODE_NAME-$VERSION/.
The reason is that on Gentoo, all you generally have to do is rename
the .ebuild file to the new version and it "works". When a codename or
some other string is kept there that changes, I have to go in and
change a variable.

Personally, I think everything should untar to `basename $file`. So
package-1.2.3.4.tar.gz becomes package-1.2.3.4/. That's easy and
understandable. Python doesn't do this, and that is why they should
die.

(For those that noticed that OHR packages things funky like this, with
codenames in the dirname it extracts into, I'm not actually THAT
pissed off, but if that practice stopped, it would make things easier
for me to maintain the Gentoo packages for OHR ^_^)

On a side note entirely, does anyone know what backends are still
being worked on? I'd like to get rid of the allegro flags if they
don't work (and they don't -- Gentoo's stable version of Allegro is
incompatible with the FreeBASIC headers) and add others (scale2x, I'll
call it scale to hide the goof ^^,)

On 2/1/07, caron.mike <at> gmail.com <caron.mike <at> gmail.com> wrote:
> OHRDev Blog has posted a new item, 'An Open Letter'
(Continue reading)

Permalink | Reply | 2 comments |
headers
subversion | 2 Feb 2007 05:41
Favicon

SVN: pkmnfrk/988 Beginning fixing of weapon placement. Right now, standard (step) attacks

pkmnfrk
2007-02-01 20:41:36 -0800 (Thu, 01 Feb 2007)
79
Beginning fixing of weapon placement. Right now, standard (step) attacks work.
---
U   wip/bmodsubs.bas
Permalink | Reply | 4 comments |
headers
David Gowers | 2 Feb 2007 05:49
Picon

Re: OHRDev Blog has been updated!



On 2/2/07, caron.mike <at> gmail.com <caron.mike <at> gmail.com> wrote:


One of the reasons it is not done in general is that lingering build files tend to fuck things up majorly.
Among other things:
   * lingering .o files causing linking errors (references to obsolete symbols)
   * duplicates/dregs of .h files causing the opposite type of confusion (mainly, include-path search order can bite you if a definition was moved from one .h to another -- duplicate/conflicting definitions)
   * Avoiding the above reliably requires a meticulously configured build system -- or simple brute force; In the OHR's case, it avoids the first problem simply by recompiling everything regardless. The second problem cannot be avoided (except by freezing the header files -- impractical.)

So it might be sort of workable to package the OHR without a wrapping directory.
I must however insist that 99% of people do NOT want to deal with the above dodginess, which can be VERY confusing and waste hours or days to figure out.

It's also trivial to script what you want using sh or python. Hint - extracting into an empty directory means that * will match only the only directory there.

_______________________________________________
ohrrpgce mailing list
ohrrpgce <at> lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Permalink | Reply | 1 comment |
headers
Mike Caron | 2 Feb 2007 05:54
Picon
Gravatar

Re: SVN: pkmnfrk/988 Beginning fixing of weapon placement. Right now, standard (step) attacks

On 2/1/07, subversion <at> hamsterrepublic.com
<subversion <at> hamsterrepublic.com> wrote:
> pkmnfrk
> 2007-02-01 20:41:36 -0800 (Thu, 01 Feb 2007)
> 79
> Beginning fixing of weapon placement. Right now, standard (step) attacks work.
> ---
> U   wip/bmodsubs.bas

This code is madness incarnate. It uses non-euclidean screen geometry
to draw the sprites (trying to get the weapon's top-left and the
hero's top-left corners was an excercise in frustration).

However, I will perservere. Eventually.

--

-- 
Mike Caron
Final Fantasy Q
http://finalfantasyq.com
Permalink | Reply | 3 comments |
headers
David Gowers | 2 Feb 2007 06:00
Picon

Re: OHRDev Blog has been updated!



On 2/2/07, Keith Gable <ziggy <at> ignition-project.com> wrote:
Keith -- http://www.python.org/download/ says you're a liar. Both Python-2.5.tar.gz and Python-2.5.tar.bz2 hold one directory, Python-2.5
_______________________________________________
ohrrpgce mailing list
ohrrpgce <at> lists.motherhamster.org
http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
Permalink | Reply | 1 comment |

Gmane