[Galladin]

merder, on Jun 23 2005, 10:20 AM, said:

i know i started this suggestion in another topic but there it was adviced to post in this topic so i'l post it here.
tools in the tile editor. like:

• flood fill
  
• ellips drawing
  
• rightangle
  
• rounded rightangle

heheh...yeah...good ideas.

[Dr Lancer-X]

I think merder has the right idea- in addition, I would like the following added to the char editor-

- Gradient fills
- Anti aliasing tools
- Magic wand
- Spray can
- Picture tube
- HSV sliders
- Font tool
- Drop shadows
- Ripple effects

[Dr Lancer-X]

merder, on Jun 23 2005, 10:20 AM, said:

i know i started this suggestion in another topic but there it was adviced to post in this topic so i'l post it here.
tools in the tile editor. like:

• flood fill
  
  
• ellips drawing
  
  
• rightangle
  
  
• rounded rightangle

Also, there is already a floodfill- it's like alt-f or something

[Tox]

Lancer-X, on Jun 23 2005, 06:15 PM, said:

I think merder has the right idea- in addition, I would like the following added to the char editor-

- Gradient fills
- Anti aliasing tools
- Magic wand
- Spray can
- Picture tube
- HSV sliders
- Font tool
- Drop shadows
- Ripple effects

With the larger character editor and SMZX mode, antialiasing isn't out of the question, though. One of the few things I like about SMZX mode is the ability TO antialias. As with gradient fills. A font tool could be substituted with a select-copy tool. Um... someone will murder me for this, won't they.

[Dr Lancer-X]

my post was a joke :(((

[Koji]

You know what would be cool an option to render the vlayer area as a screen sized 8bit graphical plane drawn on top/below the normal overlay.

Would this really be so horrible to add? or difficult to make? I mean we're using SDL now... and I know a few others who think it'd about time we had some actual pixel graphics.

[CJA]

By adding pixel graphics, we'd be destroying the very foundation of MegaZeux. I like the 256 chars and the bad graphics. That is more like a MZX 3.0 topic.

[Koji]

... no the foundation will still be there, this will just add functionality and the ability to have better graphical effects without using up all your chars.

Look people will still be able to make normal mzx games just as even though there are sprites, not all people use them.

Adding functionality to mzx isn't destroying anything, it's expanding on it. And if you can't see that.... I just donno what to say, perhaps you'd like to switch back to good ol dos.

This post has been edited by Koji: 24 June 2005 - 04:01 AM

[Tox]

Lancer-X, on Jun 23 2005, 10:10 PM, said:

my post was a joke ((

I'm aware of that. That's why I replied, pointing out that some of them could actually be acheived. O_o

[Dr Lancer-X]

Koji: Unless Exo figures out some way of disabling this functionality on Logicow's computer, we're not having it. Sorry, but that's the end of the story.

[Exophase]

Lancer-X, on Jun 24 2005, 07:03 AM, said:

Koji: Unless Exo figures out some way of disabling this functionality on Logicow's computer, we're not having it. Sorry, but that's the end of the story.

Are you kidding? This would make LogiCow's demos seem awfully old hat.

But in all seriousness, this just isn't happening (at least not for MZX 2.x). HERE'S WHY

1. Robotic isn't powerful enough to drive an entire 640x350 display in realtime.
2. The vlayer is currently only 256x128 anyhow.
3. Such a layer is pretty lame without the ability to load images to it. Since MZXers aren't about to write a PNG loader in Robotic we'd probably see a bunch of huge BMPs or MZMs accompanying the worlds.
4. Rendering a 640x350 image over the overlay would more than double the rendering time. Rendering it under the overlay would increase it even more, forcing the board rendering into two passes itself.
5. Since this layer would lack tiling or collision you'd see people attempting to write entire rendering/collision engines in MZX, not unlike what LogiCow is already doing.. but for most people this defeats half the purpose of MZX.
6. The other usage would be for FLASHY SPECIAL EFFECTS on top of the MZX board, which would make the games look unbalanced (two color tiles with FULL MOTION VIDEO overlayed on top!) and you wouldn't see a lot getting done since it'd take a while to get anywhere.
7. There's no "we" in "Exophase"

Now let me make something clear. MZXers have still been plodding away at game making but they haven't exactly been releasing top notch games every day. The features I've added in my entire run here have mainly been to make game development easier, not enable the making of fancier games. Yes, even sprites, because a lot of people were already screwing around with multichar stuff and it was causing serious development times for them. This wouldn't make anyone's life easier but LogiCow's (and he doesn't really make games anyway). For this would just be something that makes them feel compelled to add substance-less flash to their games that they already have little hope of completing.

So, denied.

- Exo

[Koji]

k good points, especially the no "we" in "exophase". =D

[Frobozz]

Exophase said:

MZXers have still been plodding away at game making but they haven't exactly been releasing top notch games every day.

About the only one I've seen worthwhile (or at least for me) to play was the DoZ entry where you run from the hotdogs.

This post has been edited by Frobozz: 26 June 2005 - 08:20 AM

[Elig]

Someway to (atleast optionally) edit the graphics of the robot's text display box (That is, the [ box). A few thoughts on it's implementation: You could use a sprite as the location and size of its graphic, a built in counter could indicate which sprite to use. Or, you could use builtin X and Y counters to reference where the message box's graphic starts. Overlay/VLayer could be indicated in the standard "#whatever" etc. way. You need not even have the width or height variable, people who wanted to use such a thing would make room for it somewhere on their board/world. In terms of the message box using a seperate character set, only the text need use that seperate character set. Ofcourse that would probably warrent someway to change which characterset the [ message box text used during run time.. If there isnt already. If you dont feel like implementing any of this, then some way to turn off the message box background (Everything aside from the text itself) would be just as useful.

Just some random thoughts I had.

This post has been edited by Elig: 26 June 2005 - 09:04 AM

[Exophase]

Elig, on Jun 26 2005, 04:03 AM, said:

Someway to (atleast optionally) edit the graphics of the robot's text display box (That is, the [ box). A few thoughts on it's implementation: You could use a sprite as the location and size of its graphic, a built in counter could indicate which sprite to use. Or, you could use builtin X and Y counters to reference where the message box's graphic starts. Overlay/VLayer could be indicated in the standard "#whatever" etc. way. You need not even have the width or height variable, people who wanted to use such a thing would make room for it somewhere on their board/world. In terms of the message box using a seperate character set, only the text need use that seperate character set. Ofcourse that would probably warrent someway to change which characterset the [ message box text used during run time.. If there isnt already. If you dont feel like implementing any of this, then some way to turn off the message box background (Everything aside from the text itself) would be just as useful.

Just some random thoughts I had.

What all of this gets down are limitations of MZX itself, however, even in its current state it's not that hard to implement what you're saying manually. The [ command isn't up for grabs though. It'll never change. Ideally you'd see a global function implemented (and very easy to import) so that something like this can be done:

do message_box("IM A MESSAGE BOX")

do message_box(10, 10, 5, 5, "TINY")

set result message_box(10, 2, 70, 6, "PICK UR OPTIONS WISELY", 3, "stay", "leave", "die")

And people think Exotic is just Exophase's expression of his inability to have fun :\

Anyway, what you'd do NOW is go to a subroutine that sends the global robot to some thing, setting up counters along the way. The key things missing are: parameters/return values for functions and the ability to have a robot go to a function that isn't part of its primary functions (inheritence, global functions)

- Exo

[Seventh Shade]

Exophase, on Jun 26 2005, 05:18 AM, said:

And people think Exotic is just Exophase's expression of his inability to have fun :\

Damn it, Exo get over it

[Pyro1588]

could you please remove wavs from the alt+n menu? still allow them to be set through robots or even allow their names to be typed in the menu, but i have a bunch of sound effects and every time i try to select a mod, i have to sort through about thirty wavs to get to one mod file.

[Exophase]

Pyro1588, on Jun 28 2005, 07:00 AM, said:

could you please remove wavs from the alt+n menu? still allow them to be set through robots or even allow their names to be typed in the menu, but i have a bunch of sound effects and every time i try to select a mod, i have to sort through about thirty wavs to get to one mod file.

No. It shouldn't be hard to just type the name of the mod in the file list...

- Exo

[Koji]

I know that in the BWSB library there wasn't a readily available function or value you could call to get the position within the order being played, the mod was playing at.

However the new modplug library might have that option.

for the sake of musical ques and timing can we add a mod_position counter that tells what position it being played of the mod order?

This post has been edited by Koji: 28 June 2005 - 08:22 PM

[Dr Lancer-X]

Koji, on Jun 28 2005, 03:22 PM, said:

I know that in the BWSB library there wasn't a readily available function or value you could call to get the position within the order being played, the mod was playing at.

However the new modplug library might have that option.

for the sake of musical ques and timing can we add a mod_position counter that tells what position it being played of the mod order?

libmodplug/sndfile.h said:

UINT GetCurrentPos() const;
UINT GetCurrentPattern() const { return m_nPattern; }
UINT GetCurrentOrder() const { return m_nCurrentPattern; }

[Koji]

Can we get that added in the next version? And by we I mean Exo

[Exophase]

Koji, on Jun 28 2005, 10:27 PM, said:

Can we get that added in the next version? And by we I mean Exo

My original answer was no, however, I might need it so there will be a mechanism of controlling the positions of OGGs. It's fairly anti-policy for me to add counters to MZX 2.8x though.

- Exo

[GetDizzy]

He's like linus. Except instead of 2.4.x being "Stable" and 2.6.x being "Testing" its 2.8x being "Stable" and 3.0 being "Vague yet interesting concepts"

[Pyro1588]

linus? the snoopy character?

[Spectere]

I...think he's referring to Linus Torvalds.

This post has been edited by Spectere: 01 July 2005 - 04:47 PM

[Terryn]

Here's a pair for you:

<Terryn> Hey, a small indicator of x/y of the current Robot during editing would be awesome.
<Terryn> (during the Robotic editor, I mean)

<inmatarian> Theres one hell of a feature for MZX. An automated Copy Block process. Press like ctrl-fnord in the editor, and you see the board and cursor, move cursor, press enter, and it gives you the X and Y of that location in the editor.
<inmatarian> I mean, tons of commands depend on X Y locations. It'd make perfect sense.

[Spectere]

I'd like to second both Terryn and inmate's ideas.

With inmate's idea, it would be even more useful if you could toggle the overlay in that view mode, perhaps by pressing 'O'.

[Lachesis]

ZOMG those suggestions sound sexy, though I didn't quite get the second one.

[Pyro1588]

nor did i. was he talking about the repeated copy block where you press ctrl+dir?

[Exophase]

Terryn's idea is easy to implement but I can't see why you all actually want it. Very rarely should it be useful to know the exact fixed coordinates of that particular robot.. you could use relself or thisx/thisy anyway, and if you move the robot it'll still be relative. That aside there isn't really any room (coordinates need at least 11 chars)..

inmate's idea has some merit but the truth is that it's WAY WAY too complicated to implement, so use MZMs or const counters or something.

- Exo