OHR - A modern GUI / interface for custom.exe

We can have this too.

You forgot to read the last paragraph genius.

*reads*

I am much more enlightened and humbled by being called out, but I'm afraid that the new information I missed doesn't create need to alter my post. Thanks for helping me out though.

You forgot your comma, genius.

Purge this whole second page (including my post).

---

Super Walrus Land: Mouth Words Edition

Newbie has become embittered and argumentative over the years.

---

Mega Tact v1.1
Super Penguin Chef
Wizard Blocks

What I would like to see is a shared library for OHR, and this can be done using FreeBasic:

http://www.freebasic.net/wiki/wikka.php?wakka=ProPgSharedLibraries

This way whoever complains about the front-end can just use the shared library APIs to edit their RPGs in their own custom editor. 'nough said.

Shizzle, if that happens I wouldn't call it dead so much as... maybe life-support. Enhanced, modernized.

I chose the ohr over verge and rpgmaker because I could make most of what I wanted before having to learn how to script. But I never used the built-in sprite maker. I imported from the start. I've used the tile image editor a little, it's a nice convenience.

My main issue is the palette. It's not worth the hassle to make sure all images conform to a single 256 pal.

There's no need for it anymore: the space it saves doesn't matter in this new era of faster pipe and short games that run over 10MB because of a few sound files.

And fluttershy, yay!

I will re-affirm that I am committed to the keyboard-driven interface, and any mouse-driven menu interfaces would be extra and optional.

If I seem to talk excitedly about the Editor-Editor plan changing everything, it is only because I mean that it will change a lot about the source code, not about the interface. It will allow me to remove a ton of old ugly messy source code, and make it easiest to work on new stuff, while still having an interface that looks and works pretty much the same as it does now.

The only thing that truly demands a mouse is the map editor (zoom levels would be helpful to go with it).

I disagree with this. Importing photo realistic images, I can understand, but for pixel art 256 colors is quite enough, and you can have multiple master palettes now.

I agree with you and I understand how useless it is to even voice this, but what I mean is the pain for all of us who haven't mastered graphics gale or whatever program you use.

To get a sprite into the ohr, you have to lower the colors to 4 bit. 4 bit! You can't defend this. At least allow the option to import gifs.

I should correct myself: I did use the ohr's sprite editor a lot. Not because I wanted to, but because I had to, to manage stupid 4bit palettes. Like making NES games in the year 2012.

Oh, I see what you mean now. The OHR needs to automatically convert images to 16 colors and nearest match colors, even if image quality is lost in the process.

Or rather we should get rid of the 4 bit limit.

Now obviously we can't get rid of per-sprite indexed-into-master palettes, because both palette swaps and master palette modifications (ie. single shared master palette) need to continue to work. So making sprite palettes bigger than 16 colours (up to 256) is a natural extension.

If you're using a (copy of the) 256 colour sprite palette that just maps straight to the master palette, then the sprite editor can just pretend that you're using the master palette directly. Otherwise, having one 256 colour palette mapping into another is rather messy (and you surely don't want them both onscreen at once). Sprite palettes should probably be variable length rather than length 256.

Unfortunately remapping huge palettes would also be way too much work without some special tools. There's an alternative, see below.

I guess we'll have to wait and see how well it works in practice.


Well the problem is, you can't really use them. Being able to use multiple master palettes at once would be quite nice. It would allow lots of stuff like fading out the whole screen except for some object(s) or a text box (requested many times), and using a different palette for error messages or the UI in Custom. Custom would probably be much more colourful.

That requires switching from 8-bit to 32-bit colour display internally (bonus: alpha transparency), which Jay has actually already put a whole lot of work into.