[Lachesis]

Put key_code and key_pressed in the F6 debug screen

[Terryn]

ajs, I was planning on combing through this thread myself anyway. Har.

I've been busy with miscellany recently, but I'll get cracking on things soon enough.

PS: To Kuro, you forgot key_release, I assume? Consistency helps when you ask to graft things onto MZX.

[Lachesis]

Terryn, on Aug 7 2007, 06:10 PM, said:

ajs, I was planning on combing through this thread myself anyway. Har.

I've been busy with miscellany recently, but I'll get cracking on things soon enough.

PS: To Kuro, you forgot key_release, I assume? Consistency helps when you ask to graft things onto MZX.

actually, i didn't know about key_release

[Exophase]

It was already explained why having those there wouldn't really be sensible (although I can't for the life of me remember where), and it's such a meager thing anyway (engine to report key_pressed = a few seconds of code - put it in a board somewhere, it'll be easier than holding the key then pressing F11)

[Lachesis]

Exophase, on Aug 7 2007, 06:50 PM, said:

It was already explained why having those there wouldn't really be sensible (although I can't for the life of me remember where), and it's such a meager thing anyway (engine to report key_pressed = a few seconds of code - put it in a board somewhere, it'll be easier than holding the key then pressing F11)

me said:

Put key_code and key_pressed in the F6 debug menu

[Val]

Kuroneko said:

me said:

Put key_code and key_pressed in the F6 debug menu

Kuroneko said:

Put key_code and key_pressed in the F6 debug screen

This post has been edited by Guy: 08 August 2007 - 02:09 AM

[Lachesis]

Guy, on Aug 7 2007, 07:08 PM, said:

Kuroneko said:

me said:

Put key_code and key_pressed in the F6 debug menu

Kuroneko said:

Put key_code and key_pressed in the F6 debug screen

and that matters so much because WHY

[Exophase]

Kuroneko, on Aug 7 2007, 09:20 PM, said:

Guy, on Aug 7 2007, 07:08 PM, said:

Kuroneko said:

me said:

Put key_code and key_pressed in the F6 debug menu

Kuroneko said:

Put key_code and key_pressed in the F6 debug screen

and that matters so much because WHY

This is more sane to implement BUT it would take up more space on the debug box which makes it more obstructing, for something so minimally useful. My vote is no.

(and of course it's really confusing calling that thing a menu or a screen when it's neither)

[Elig]

First, I want to say that I agree with 100% of what Exo said, with the minor exception of having grids. The grids I am sure that everyone would look upon as a "hack" of sorts, as I would personally choose to implement them in the very final stage of rendering, directly to the SDL display surface, with a configurable option as to the style and nature of the grids etc. Anyway, I might end up implementing this as a quick proof of concept, simply to get it out there. Aside from that, I think Exo's completely right about why further features aren't implemented into MZX. Never the less, having talked more and more with Lancer, I cannot help but find the idea of adding better loops and such into MZX a good idea. I mean, looping in MZX is simply an absolute nightmare, and has always been. Surely, atleast for the sake of sanity during DoZ time, we should think about whether or not to add better loops. Also, Exo further raises many, many good points about pixel based sprites which I had not even considered.

[Exophase]

If you're going to start changing Robotic in that kind of way then the right thing to do is to separate the source code from the bytecode generated. Otherwise you're going to be working against all sorts of problems the entire time, and everything will always feel like a hack. This opens the door to all kinds of new things, including loops, comments/whitespace that aren't part of the bytecode, macros that aren't auto-expanded, and much better labels (and counters if you go that far). But it'll take some changes to RASM to get all this in.

How this can be done: use an invalid size for the robot (like 0) and then have sourcecode embedded, and compile this when the robot is loaded. Modify the editor to work with the sourcecode and don't have it compile (unless you want to check validity, but that can be done easier than compiling, probably). And change RASM to be more gracious with whitespace, including allowing newlines.

Don't implement grids unless you can at least rationalize why they should be there and convince someone else that they're worth something.

[Koji]

Exo, I was talking about that instance of code.

And pixel perfect positioning is enough to emulate pixel perfect scrolling if you don't know how, you make the sprite BIGGER than the screen, and move IT around, not the reference points (you only need to move them if the view moves out of where the sprite is currently referenced)

reference points are rounded to to the outer most characters, and sprite position is moved around sub character.

Of course yeah this is something that would have to be implimented in robotic, I wouldn't want this implimented in the core of mzx, since it's doable in robotic IF you have pixel perfect placement of sprites.

right now yeah the sprites are constrained to character positions, and even the sprite writing algorithm is constrained to character positions, but not so long ago, some people were making versions of mzx with the ability to copy a section of pixels on the board to locations on the screen, what if the sprite drawing algorithm handled sprite drawing more like this?

This post has been edited by Koji: 08 August 2007 - 01:45 PM

[Exophase]

Koji, on Aug 8 2007, 08:44 AM, said:

Exo, I was talking about that instance of code.

And pixel perfect positioning is enough to emulate pixel perfect scrolling if you don't know how, you make the sprite BIGGER than the screen, and move IT around, not the reference points (you only need to move them if the view moves out of where the sprite is currently referenced)

reference points are rounded to to the outer most characters, and sprite position is moved around sub character.

Of course yeah this is something that would have to be implimented in robotic, I wouldn't want this implimented in the core of mzx, since it's doable in robotic IF you have pixel perfect placement of sprites.

right now yeah the sprites are constrained to character positions, and even the sprite writing algorithm is constrained to character positions, but not so long ago, some people were making versions of mzx with the ability to copy a section of pixels on the board to locations on the screen, what if the sprite drawing algorithm handled sprite drawing more like this?

Logicow's hacks drew things strictly on top of the screen, unlike sprites which can be either under or over the overlay, so no.

[NoahSoft]

I'd like 2 things...

1. To be able to move boards around the board list. Like if you forget to make a board for the middle of the game, it has to go to the end of the list, and that is annoying to scroll through. This one doesn't seem that hard?

2. A way to randomly pick from a list.
Example: Set "local1" random 2 or 45 or 27.
So it picks either 2, or 45, or 27. I know you can do that with more code, but a simplified version would be nice.

[LogiCow]

Copied from some other thread:

Just make a button layout that works for everything, and that can be mapped to:
1) the keyboard, with arrow keys and Z, X, C, A, S, Space, Enter
2) A nintendo DS, with D-Pad, A, B, X, Y, L, R, Start
3) A PSP, similar to the nintendo DS

And while configurable, the default keyboard layout would be like this:
Keyboard "Z" = DS "B" = PSP "X"
Keyboard "X" = DS "Y" = PSP "Square"
Keyboard "C" = DS "X" = PSP "Triangle"
Keyboard "Space" = DS "A" = PSP "Circle"
Keyboard "A" = DS "L" = PSP "L"
Keyboard "S" = DS "R" = PSP "R"
Keyboard "Enter" = DS "Start" = PSP "Start"

Except enter has a stupid menu in MZX so maybe start would be something other than enter. But Start really should be enter. It's main purpose is to pause the game anyways.

And make it easily accessible through counters in robotic, so that future games have no reason not to use them.
Like "Joy1" "Joy2" "Joy3" up to "Joy7"
Or since everyone ever has played SNES, make it more visual:
"JoyA" "JoyB" "JoyX" "JoyY" "JoyL" "JoyR" "JoyStart"

And heck, maybe even remap the player movement to that, so that you can play through caverns without having to reconfigure stuff. But that's entirely optional.
The focus is on new games, since it's hard to make the broad range of previous games work without custom layout for every game.



To recap: When making your future MZX game, you use the "JoyB" counter to detect if the player jumps and "JoyY" to detect if the player attacks. That way it also works on nintendo DS and on PSP. And on a computer, it'll be Z to jump and X to attack. Which is perfectly fine and pretty much the modern standard.

[Old-Sckool]

How about making it easier to animate the board/overlay within robotic somehow?
I also think that it would be neat to make it so that if you don't write in a label at the end of an IF command, the following line would be skipped over if the statement was false.

[RyanThunder]

For future MZX development, I suggest making text characters COMPLETELY separate from the initial 256 chars.

That way, you'd have a char editor AND a font/text editor.

I dunno how hard this would be to implement but it would be extremely useful nonetheless.

[T-Bone]

That would be pretty awesome.

[CJA]

Logicow has a good idea going.

Also, there should be a way to set individual volumes to 0 (turn them off), even if it's just using the config file. Putting in music_volume = 0 makes it go to 1, which is still well audible.

[Spectere]

There is, CJA. Use music_on to enable/disable digital sound (music and WAVs) and pc_speaker_on to enable/disable the PC speaker sound effects. Those two lines should be provided right above the volume level adjustments.

[CJA]

Yes, but I want music off and sound effects on.

[ajs]

Or, as many people don't realise, simply on the command line:

mzx281g video_output=opengl2 music_on=0

I prefer this method because then I can use the default config (which being the person installing MZX 3-4 times a week, really becomes a pain otherwise).

@CJA: I'll check that out and fix it, does seem like an oversight.

--ajs.

[RyanThunder]

Speaking of volume stuff, being able to set MOD and WAV volume separately in the editor would be awesome.

Instead of this:

volume 255

We should have this:

mod volume 255
sam volume 255

I can't tell you how many instances where I wish I had 2 separate volume levels.

This post has been edited by RyanThunder: 23 November 2007 - 06:27 AM

[CJA]

Hmm... It wouldn't be too hacky to have a "modvolume" and "samvolume" counter, huh?

[RyanThunder]

Do you know how to do something like that? If so, I guessI wouldn't need that feature anymore!

[RyanThunder]

CJA, what I mean is that the "volume" command is global; it affects both MOD and SAM volume levels globally. I want it where you could have an instance with really quiet music, but with normal volume sound effects.

[Terryn]

I'd like the F11 menu to be strengthened a bit. The seeking is only one character deep, unlike the file dialogue's, and I'd like it to be as strong as the file dialogue's seek. (So if you're trying to jump to counter r50 out of r0-r55, for example, you can only jump to the first counter that starts with an r (in this case, r0) instead of directly to r50.) The ability to newly set counters/strings in F11 might be beneficial too, probably done by a "Set New..." button that jumps to a screen in which the user can set the counter/string name in one field and the value of said counter/string in another.

[CJA]

The ALT-F menu should show you the index number of the SFX you're editing.

[nooodl]

CJA, on Dec 9 2007, 07:11 PM, said:

The ALT-F menu should show you the index number of the SFX you're editing.

Maybe "sfx ..." should also work with typing for example "sfx MagicGem" or "sfx Lava".

[Why-Fi]

Castlevania, on Jun 4 2005, 12:16 PM, said:

Okay, it was worth a try though. I know how to do the macro thing but I just suggested this because it would have been more accessible and easier to manage. If you scrapped built-ins in MZX3 then a thing like this would be really helpful, especially if you're thinking about replacing them with an import robot option instead. I'm just thinking about the new guys that's all.

I don't think I have any more requests for MZX2.x now, I guess I'll just have to wait until 3 comes out.

Yeah, I've already read this post, wrote down your requests and MZX 3.00 should be here Fall 2008!

Don't worry, there's room for everybody's requests!

[asiekierka]

Add AVI support, why-fi.
Add NES/GB/GBC emulators to MZX, why-fi.