dMZX Forums: hseiken - Viewing Profile - dMZX Forums

So I'm playing around with a sprite, using sprite 0 as a player controlled entity and I have this bit double up for each direction:

: "tryUp"
copy block at 21 29 for 3 by 4 to 21 32
if c?? Sprite_colliding p?? at "spr0_x" "(&spr0_y&-1)" then "doInputs"
if spacepressed then "doUpAttack"
dec "spr0_y" by 1
cycle 1
goto "doInputs"

Now, the intent was for the sprite to collide with a wall and not do anything. Dunno why it wasn't working, that's not the issue. The issue is that this code DOES make the sprite stop. In seemingly random places and the BLOCKABLE/SOLID/NORMAL blocks I have on the map do affect it...but it's so random...consistently so.

So In one map, I have copy and pasted an artsy fartsy collection of customblocks and made a solid rectangle around a single screen...and the sprite will detect a wall in the middle of the screen both horizontally and vertically. On a different board with the same robots and sprite, etc and this one is just a simple solid wall all the way around, the sprite stops randomly around apparently a single character block near the bottom left of the board.

ANd changing NOTHING about the boards, I switched all the code referencing sprite 0 to reference sprite 1 and suddenly, no more hidden walls...(now I can figure out why my collision detection code isn't working! LOL)

But was wondering if there's quirks to sprite 0 and/or maybe this is a bug? I can post a sample board if needed.

When using bound sprites in the MSDOS version of MZX, what is the 'general tradeoff' of commands processed per sprite? Is that measurable on my end with some robotic code to get frame rate or some other kind of useable readout for this sort of performance tracking? I'm not even going to try unbound sprites.

As well, is there a board tile limit that begins to impact performance? I recall the older DOS-ONLY MZX had a board size limit, so removing that limit surely can have an impact in terms of memory access? Again, if there's some code snippet to plug into a robot that gives some kind of performance feedback would be maybe most useful? At least when using the newer features like sprites...I haven't seen any performance issues with having 255 robots making a disco out of a board yet..but just a few bound sprites and it crawls...

Maybe I'm not understanding out a frameupdate is determined and that can help with optimizing sprites, too? But again, i don't even know how to code a frame report gadget...gah...

I hope this line of questioning makes sense as to what I'm trying to ask very poorly. I didn't put this in robotic talk as I felt it sort of overlaps into general MZX operation with regards to the the difference of just executing robotic vs. executing robotic AND splashing a sprite onto the screen. Apologies if this isn't the place for clumsily worded post.

Before anyone gets all bent out of shape, this post is in jest and is mostly about the silliness of words spelled vs. words said..

MEGA.

I have no issues with this part.

ZEUX.

I have issues with this and how everyone says it. Huge issues.

First, I feel that if anyone involved with the project wanted to call it ZOOKS, they would have, first off.

Second, is there a collective memory hole that everyone has fallen into in which they don't know that these names and words exist?

1.) PAPPADEUX. Pronounced PA-PA-DOE. DOE. Not DOOKS.
2.) EUX suffix in french. Pronounced OH as in, "oO, I dind't know it was pronounced that way"
3.) MILLIEUX. Pronounced MIL OH.
4.) Insert literally every word that ends in EUX and no one OOKS it up.

So, in the future, please, use the French way to say it. It just sounds more classy. Zooks? That just reminds me of GADZOOKS, that gaudy mall teen fashion hell hole from the 90s.

(please, again, this is all a joke, don't take it seriously!)

So I tend to get ideas and what to try those ideas then get stuck somewhere on the idea for whatever reason. Either I'm unsure if it's really fun because, well, just because I find something jolly novel doesn't mean everyone else will. And so I start thinking, "Eh, is this REALLY the cool thing to devote my attention to?"

This leads to a lot of noodling. And my noodling in MZX leads me to asking questions about how this or that works. So rather than post a new thread every other day in Robotic Talk, I'll just throw them in here.

My latest noodling is trying out a concept I stumbled upon while trying to make some Twin Stick shooting action with MZX. Basically, I didn't understand MZX well enough to do what I wanted to do, and this time I came in knowing this and decided to stick with the more 'vanilla' mzx commands to see how far I could get. And apparently, very VERY far. One of the questions I had already was how to get ring and potion effects when there's no command for all of them and you can't PUT an item on the player to simulate an instant effect...and their 'hack' was like...not evident to me that it made me realize I don't know anything at all about the original pre-sprite-engine mzx at all, so...that's a lot of what I'm playing with...pre-sprite era stuff just to see how far robotic 'extends' mzx.

At any rate, the twin stick noodling thing that didn't go right the first time spawned an idea...what if robotron but you don't shoot, turrets around you do...and you can get shot by them so you should not do that...and that's what i've been noodling on.

Here's a video of me trying to speed run this test level without doing one of the main mechanics of the game which is deactivating the enemy generators on the way to retrieve the mcguffen so the return doesn't have as many enemies. I also forgot I had the super bomb I just learned how to program in with avalanche then change the rocks into explosions and make the player invincible for a couple of cycles so it doesn't kill him....learned all that for situations like i had there...and forgot that's a game element lol

https://youtu.be/qllEwjvHkWE

Oh well!

Right now I'm looking at how to refactor the robotic that handles the zone activation and scrolling. Currently it's hardcoded to 4 zones of 4 specific colors, so I'm now looking at how to make it so a level robot will store the level data with all of the zones, their colors, etc. and a global bot will figure all that out and let the robots used as sensors sort it out cause i'm using ALIGNEDNS and ALIGNEDEW along with HORIZPLD and VERTPLD to create 'infrared sensors' to shift zones....you can see them in the video, there's two white blocks near the zone changes. one of those white blocks is a robot, the other is just a white block. It sends a message that the zone changed so the main zone controller gets new cordinates of where to scroll, what walls to bright and what walls to darken, and all of the generators run independently, so they're just running if the zone is set or not. Same with the guns, they just keep checking if their zone is active or not.

Welp, I'll be asking all my questions here from now on, I guess. And showing other noodlings, of which I've many. One of them is a rather sizable collection of ANSI art I made in service of a game that UFO50 beat me to, but mine was going to be all BBS door games and such...with different BBS's to connect to for different difficulty levels and similarly with an 'underlying story' tying everything together. It's a rather giant scope of a game for one dude, especially one who digs ansi art and wanted to make it as an excuse to do a game with dope static screens...but...that's for another day.

So I'm wanting to make custom enemies and a lot of them to shoot at. Like..a lot of them per board. And I also have custom robots that make the cool border graphics. Needless to say when starting up the a stage, I'm not seeing my enemies spawn.

Not being super familiar with ZZT, I did catch this command called 'bind' which 'saves' programmatic space by having, I guess for lack of better word, 'template' program and then apparently as many instances as you want to 'bind' to it, in which they imitate the original.

This is what I THOUGHT I was doing here...


So, here's the Robotic...and it's not doing the BIND thing...of course, maybe BIND has it's limits, too. I'm not ZZT power user either. That said, it would imply to a novice like myself that the 256 robot limit can be broken if there's 'copies' made, which is what I was/am attempting to do so I can get enough enemies on screen to make even having twin stick controls feel like not enough to survive.

. "load up some grunts"
loop start
set "x" to random 2 to 78
set "y" to random 2 to 23
copy at 73 0 to "x" "y"
loop for 35

Do that for a couple of enemy types and some terrain, then plop in 200 animated robots for the border and well...enemies aren't showing up after the border is drawn.

I'm guess copy isn't what I should use for this? However, duplicate had a note that it wasn't recommended to use...so I'm not sure what to do here.