Can anyone recode EDDY (TML)

[EstTeeEfEm]

Oh, and I have another tool for you.. the PI1 to 16x16 sprite tool, its a bit long-winded but you basically end up with a pictures worth of tiles sat in the sprite editor

[exxos]

I will do, there is a merge function in the STOS sprite editor, looks like two disks, think its below "load" ...

I'll try and display the sprites a bit later maybe tomorrow.. its thus nite (officially friday for me lol)

I've created a 150 blank sprite bank, a white square first sprite, same on sprite 150, and that gets messed up..

Steem__00005.jpg

So trying im looking at the raw data in the bank in a hex editor to see if I can work out if the corruption is actually in the file itself, or being loaded into the program creating corruption... could take a while

[EstTeeEfEm]

lol... didnt think of that... when thats done i have some more atsks for you hahaha... only joking ...a simple For/Next loop that sticks random data from 0-256 into an array

[exxos]

lol... didnt think of that... when thats done i have some more atsks for you hahaha... only joking ...a simple For/Next loop that sticks random data from 0-256 into an array

I think this is going to keep me busy for a while

I don't think its bank corruption, ive filled pretty much the entire file full of zeros and its changed nothing. Though the corruption in the editor always seems to be the same. When it creates banks it fills them full of zeros, so having trouble working out why the corruption is coming from. Its pretty much as the image I posted all the time.

Though its not even displaying the white square, only 2 sides of it.. so its not even displaying block 1 correctly

[exxos]

Maybe good and bad news.. good news is I found the problem.. kinda..

So I tweaked the code which draws the blocks in the editor, I looped back to block zero if it wanted to draw over 128. So that displayed the blocks on screen ok (but block number 128 then is block zero)...

After filling the block data full of zeros, it didnt change any output on the screen. Its not just some ram not being cleared causing the corruption either as its always the same looking. So the corruption is being drawn...

So then the bad news..
I think its a limit in the extension itself More specifically "set block" command. I'm assuming it doesn't like blocks over 128 number and just causes it to screw up after that.

The lines after 790, those output the blocks on the screen. Though I dont really understand why it corrupts the world blocks like that. If you look..

Steem__00006.jpg

It looks like after block 128 it wraps around to the start of the screen again, as the white corruption parts from block 128 look like the menu bar at the top (white) then it seems to skew into your block data again. As to why it always seems to get the corruption from the start of the screen address, no idea.

Must be some odd bug in the world functions where over 128 it loses track of where the block data actually is (the block data is probably very close to where the screen memory is) so assume it gets confused and starts using the screen memory instead of using the world blocks in the data bank. Of course screen memory isn't in the format the blocks are (blocks have pre-shifting for starters) so you end up with odd corrupted graphics.

I guess TML guys never thought anyone would use more than 128 blocks, if they were double the size, then the editor screen would run out of space to display them all

Anyway, its back need needing the missing link source code, unless someone knows TML team to ask for the code, then nothing can be done ::(

Your only possible work-around is to draw your blocks in separate files, and swap the block address in real time. If you only want 50 blocks in a level, then just do that level with a 50 block bank with the world data, then your next level, use a new block bank.

Or if you really want to use more than 128 blocks on a single level, then your only option is to have something like 10 blocks which are common to every level (maybe water or something) then you use 100 blocks for the first section of your map, then fly over the water, at that point change your block bank address, as the water is same in each block bank, you will never know it just in effect loaded in more world blocks. Then when you fly out of the water area you have another 100 blocks you can use.

So..

load in bank 1 - (10 blocks of generic water) - 100 blocks of trees.
scroll for however long your first map section is
scroll over your water using first 10 blocks
load in bank 2 - (10 blocks of generic water) - 100 blocks of rocks.

Now your world in effect would have double the amount of world blocks... first 50% of your map with bank 1 blocks, second 50% with bank 2 blocks.

So when creating your world, you draw the first half with block 1 bank loaded, then second 50% with block 2 loaded. Of course this would look like the first 50% of your map is screwed up, but its why you would need to switch banks during the game play. As its just a address change, its not going to slow the game down any.

Hope that makes sense ?


The only other option is just not to use the world commands at all. Probably re-hack the STOS MAP editor to use bobs instead... I can't remember if you can scroll with the STOS MAP's function so you might have to scroll the screen yourself with SKOPY or something... I don't know if that would be to slow than using the world commands.

I would assume the world command is just using similar code to display the world blocks on screen as the bob code does, so might not be any speed difference overall. Also assume SKOPY is similar code for scrolling the screen as the world command does.. It might be worth doing a test map, just change the sprite lines for bobs, load bobs in, and just see how it looks ?

EDIT1:

I used timer=0 and print timer after it draws the 154 world blocks on screen, and timer came back as 28. I looped displaying 154 bobs in a loop and timer came back 11.

So in that test, 154 bobs can be displayed on the screen in half the time that the world function is doing it

I tried filling the whole screen with bobs and timer came back as 16. Though looking at how fast they are all being drawn on screen , it looks like a couple of seconds. I don't think the framerate is that bad with the world command

BOBTEST.zip

Might be worth doing a loop with the world command, just see how fast it can actually display a single world screen ?

EDIT2:

There is also "MANY BOB", seems the for next loop is very slow and that function solves it. So possible that could be fast enough for a world routine..

EDIT3:

MANYBOB.zip

That is awesome! It actually shows a world type map and you can move the mouse and scroll about. Looks smoother than the world function to me!

oddly, the "many bob" command isn't in the DOC.. but its in the link.bas as a example. So for next loops are ultra slow then it seems aswell..

As the bob number, X,Y locations and XY offsets are all done in a array, you dont have to mess about with banks (unless you want to store the data in banks). It probably would be simple to create a ultra simple "world" editor using many bob. You only need to store the XY locations in a array as you draw stuff on the screen, thats pretty much it.

So I would ditch the world functions and go for manybob route instead. Of course you should probably check there isn't a bob limit of 128 first Then write a new world editor, shouldn't take long. Probably design a new bank format to store the figures in.. probably just use the many bob data layout as a easy to work with bank layout..

It would just be something like X,Y,IMG,X,Y,IMG, X,Y,IMG...

So if you needed 100 screens high (about 250 blocks per screen) then thats 250 blocks with 3 bytes to store X,Y,IMG is 250 x 3 = 750 bytes per screen , x 100 screens, would need 74K of bank data.

Then have exploding stuff on your map , go remake xenon

My brain hurts now. Ask something easier next time

[EstTeeEfEm]

oddly, the "many bob" command isn't in the DOC

There should be an "UPDATE.DOC" with the new commands in.. in "theory" they're faster... do i wanna work with massive arrays for several enemies though ?

Oh, and i had a eureka moment...

TWO MAPS/TWO WORLDS ...

I can build level one using two maps and two worlds 1/2 and 1/2 ... its no slower because its all loaded in anyway, used the same trick in the shadow of the beast demo, cant believe i didnt remember?!

[EstTeeEfEm]

Right, lol...

Im going to write a new WORLD builder, the only thing i can think of now lol.
Its gonna use TWO sets of "BLOCKS" so that you can have 256 .. if i start using more its gonna get a bit complicated. Switching from one tileset to another should be fairly simple though. I just need to get the WORLD.MBK figured, are they just all data statements? seems the easiest way, esp since you can hand code the blocks using "set block" ?

[exxos]

Have you checked my "MANYBOB" file, its more than capable of drawing worlds. forget hacking about the world commands, you could write a really nice world editor in probably a few hours, you was asking for one anyway. It will save a lot of confusion in the long run.

[EstTeeEfEm]

Yea, ill have to get onto tool building at some point, like most games programmers... build tools as you go along, lol, this time next year all these little issues will have been solved

[EstTeeEfEm]

Ok, so the only way I can reliably solve the 128 tile issue is by having two sets of maps and worlds, similar in point to my Shadow ot beast demo. Its finicky to get everything lined up but it doesn't show to the user. You don't even have to display two worlds all at the same time; only over a period of 200 Y lines throughout the transition.

[EstTeeEfEm]

Have you checked my "MANYBOB" file, its more than capable of drawing worlds

I was looking at the old MAP.ACB program too... maybe a hack between that and the many bob command is probably the best way to do it.. obvs this map editor is more functional in that it saves out DATA statements too, meaning i could probably do a READ into MANYBOB array and build the worlds using the old MAP.ACB
When there is a will there is a way!!

Edit:
There is still a Sprite limit of 220 sprites but that is actually enough to do the levels.
Here is how the data is ASCII'fied

Code: Select all

50000 restore 50005:read nl,nroom:if room>nroom or room<=0 then boom:return
50001 restore 50010+(room-1)*nl:read gridw,gridh: cls physic:cls back:for I=0 to 319/gridw : for j=0 to 199/gridh:read s : if s>0 then sprite 1,i*gridw+1,j*gridh,s:update : put sprite 1
50002 next j:next i:wait vbl:sprite 1,100,-100,1:return
50005 data 25,1
50010data 16,16,0,0,0,0,0,0,0,0,0,0,42,15,0,0,0,0,0,0,0,0
50011data 0,0,0,43,15,0,0,0,0,0,0,0,0,0,0,42,15,15,0,0
50012data 0,0,0,0,0,0,0,0,43,15,15,0,0,0,0,0,0,0,0,0
50013data 44,15,15,15,0,0,0,0,0,0,0,0,0,38,37,15,15,0,0,0
50014data 0,0,94,0,0,49,4,38,37,15,0,0,0,0,73,5,0,0,50,4
50015data 4,38,37,0,0,0,0,78,6,0,0,51,4,4,4,38,0,0,0,76
50016data 79,0,0,49,3,4,4,4,4,0,0,0,77,80,0,0,50,3,4,4
50017data 4,4,4,0,0,0,0,0,0,51,3,4,4,4,4,4,0,0,0,0
50018data 0,0,4,4,4,4,4,4,4,0,0,0,0,0,0,4,4,4,4,4

Meaning, if I strip the header and read from 50010 i can literally read the data into an array for the manyBob command.. Kool!

[exxos]

I don't fully get how the data is stored, but you also need data for sprite on/off. I don't think its worth really hacking the STOS map ACB. You could patch the data output into a bank, but then its just back to hacking stuff. Might as well just design a new bank format like I suggested already and do a simple map editor like TML one.

[dml]

FWIW, this issue lay partly in the TML extension at drawing time, using signed word adds (limit of +32767) to offset into the tile bank. The tile indices are already preshifted << by 7 for indexing 16x16 pixel 4bpl tiles, and then again +1 for the extra preshift word (shifted tiles are two words wide, not one). So that leaves 7 non-sign bits for the tile index itself, before it starts going negative.

I patched the TML code to get around this but it only increases the limit to 256. The remaining limit is in the map editor itself and the preshifting <<8 of tile indices into addresses. Both the map editor and the TML drawing code would need fixed to get around the new limit of 256 tiles. Fixing TML is easy but less sure of whats involved with fixing EDDY and what other tools might be involved and need fixed too...

It also seems that there are other, separate bugs in the map editor. Probably because it was never tested > 128 tiles...