Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[osiris37]

Cheers Horace, they were exactly what I needed
*Happy Bunny*

[MadMunky]

Is there any programs in Windows I can use to read the non gif files?

[Hungry Horace]

Horace: your welcome to have my code it's very messy and badly done currently why I just try get it all working then ill go back and change it and comment it as best I can I don't see it being too hard for you to work its done in a very similar style to your brothers code as for the buttons they are all only now draw on the correct sides of the walls in the video i posted they where on all 4 sides hence why there is so many flags and shelfs but that's all fixed now.

Cool  - please send something over and i can at least have a look to see how much i can understand.  I know nothing about my brother's code tbh - too many data statements for me! I would prefer to be coming at it "fresh"

What would be a big help Horace would be if you could finish off commenting the level code like how the scrolls are done and its would be nice to fully support all the original code and not have to change anything also means your editor will work

I will try and butcher something for you today.  Di d you read my info on switches/traps which should be on this site btw?

[Hungry Horace]

Is there any programs in Windows I can use to read the non gif files?

hopefully osiris knows of a good IFF/ILBM - >  other  file converter , or a suitable plugin for photoshop to add support.

[MadMunky]

I will probably do away with this, even on an amiga based remake, in favour of having pre-coloured graphics readily available. Although memory inefficient, I don't think this should be much of an issue if the primary user-base is via emulation.

I did think about doing this also but to best honest I'm not sure what is best, there would be so many more images to store. The way I have done it is have the basic image then when the player can see the image I recolour the pixels, I believe there is a better/faster way in Java to recolour the ColorModel of a image but I'm not sure at the moment how to do this.

[MadMunky]

Cool  - please send something over and i can at least have a look to see how much i can understand.  I know nothing about my brother's code tbh - too many data statements for me! I would prefer to be coming at it "fresh"

To be honest you might be better of working from fresh and just using my code for reference, the basics of how im doing this is

Grab 18 squares of map data depending on the player rotation
Array of 32 X/Y to store where on the screen the images need to be drawn
Build the viewport up from the back forward from around 32 images to create the prospective

When it comes to the Stone Walls and the Wooden Walls you have to work out what image locations make up the 4 sides of that wall then draw the correct graphics, the trick to it all is drawing the graphics in the right order so when you building up the picture you dont redraw over something screwing the perspective

Horace, do you have a email address I can zip up and send over the code?

[Hungry Horace]

Horace, do you have a email address I can zip up and send over the code?

i should have an email icon next my avatar, or on my profile here - probably best you use that one!!


Trying to sneak a lok at scroll code at work...

[Hungry Horace]

Looking at my "scrolls.block" file, there are two sections.

firstly, at offset 0, for $92 bytes, there are $49 words. Strangelt allowing us to define 73 scrolls.

The first six of these offset values are as follows;

Code: [Select]

00 00 , 00 26 , 00 4E , 00 8A , 00 B3 , 00 CC ...
These relate to which scroll (which we will give an arbitary numbering system, starting at 'scroll 1') occurs at what offset within the data block.



This data block starts with offset 0 being thefore $92 bytes into the "scrolls.block" file.

ie.

Code: [Select]

Offset
0092 - scroll 1  (offset given 0000)
00B8 - scroll 2  (offset given 0026)
00E0 - scroll 3  (offset given 004E)
011C - scroll 4  (offset given 008A)
0146 - scroll 5  (offset given 00B4)
015E - scroll 6  (offset given 00CC)
...

The remaining $CA2 bytes contain the actual scroll data. i.e. what each one reads, and how it is laid out.

In my editor, I change the actual scroll data one at a time, adding in new bytes if needed, and capping the end. (ie. limiting the scroll data to $CA2 bytes, and forcing a termination byte at the end if required.)


I then simply update the header data, by reading through my scroll data, and writing in the updated offset values accordingly. This ensures the two stay correctly linked.


Given that each scroll has at least one "start new line" and must have an "end" (termination) byte, updaint the header is quite easy to do. if I dont find 74 scrolls worth of data, thne remainder offset values would be set to "0" to prevent any confusion. (so the remaining scrolls will simply look the same as 'scroll 1')



for defining each individual scroll, there is a standard layout. 3 bytes of info. followed by the ASCII data. The scroll is then terminated with an $FF value.

E.g:


FC 1E 04   -  Start line Byte , X position, y Position
54 48 45 20 4B 45 59   - ascii text  (the key)

FC 1F 05  -  Start line Byte , X position, y Position
41 42 4F 56 45   - ascii text  above


FC 1E 06   -  Start line Byte , X position, y Position
44 4F 54 48 20 4C 49 45    - ascii text  (doth lie)

FC 1F 07   -  Start line Byte , X position, y Position
42 45 4C 4F 57    - ascii text  (below)

FF  - Termination



x position and y position limits i cannot remember, but can find from my editor later.



Somewhere it must also be defined that for tower/dungeon 2-6, the "scroll 1" starts at a particular offset. (althogth i do not know where.

Maybe if we can work out the offsets for each "scroll 1" we can find it, and adjust that also!

[MadMunky]

Thanks Horace,

I'll take a look at that when I get onto that part of my code, I've done another video take a look and let you know if you see any problems

http://www.youtube.com/watch?v=aRxmpSrKQ5k

I know the walls dont line up correctly but apart from that everything else should be OK now but i've been looking at this for so long I might have missed something

[MadMunky]

Just found this on the other thread about scrolls so will post it here..

Ok, a quick read-through of that scroll data, reminds me that we have two "sections" of the scroll information, within the scrolls.block file.

Part 1 - is a list of word-values, declaring how many bytes into the part 2 each scroll begins.

e.g. Scroll #001 will always begin at value $0000, so this is the first value.
If scroll #001 is $20 bytes long, then the next value will be $0020 , if scroll #002 is $12 bytes long, then the third value will be $0032 etc.

Part 1 is $0092 bytes long.

this is the original $92 bytes of data from BW, laid out in a meaningful way.

Code: [Select]
0000 0026 004E 008A 00B3 00CC 00DE 0127
0145 0180 019B 01B4 0207 0220 0252 0269
028A 02A9 02D3 02EB 0340 037B 03A8 03C0
03E9 040C 0444 047C 049D 04D3 0500 0525
054F 056D 0593 05C2 05FE 0642 0667 067E
06B7 06DB 0709 0731 076F 07A3 07D6 0802
0837 0858 087C 08A3 08BA 08E1 092E 0950
0987 09A6 09D0 0A0B 0A29 0A40 0A67 0AA2
0AED 0B14 0B4C 0B77 0BA2 0BCE 0BFA 0C32 0C5D

Part 2 is simply a list of the scrolls, with a specific "format", this is $CA2 bytes long.

here is the very first scoll entry from BW, also in a format to make it understandable:

Code: [Select]
FC 1E 04   54 48 45 20 4B 45 59
FC 1F 05   41 42 4F 56 45
FC 1E 06   44 4F 54 48 20 4C 49 45
FC 1F 07   42 45 4C 4F 57
FF

in-game this reads:

Code: [Select]
THE KEY
 ABOVE
DOTH LIE
 BELOW

- Byte 1: $FC should be seen as simply a "line declaration", so the first scroll can be seen to be 4 lines long.

the following two bytes, are effectively an X/Y coordinate for placing the scroll on the screen.

- Byte 2: X Coordinate
$1E should be seen as zero however, as any lower value than this will not be on the scroll on-screen.
In order to keep the text on screen, the length of the text on each row, determines the maximum value of the X coord. I.e. if you have a row of only 1 character long, you can have a maximum X value of 8 (therefore value $1E + $08 = $26 can be patched in) ... if you have a row of 3 characters, your maximum  X value is 6 etc.

You can fit a total of 9 characters into a row only.

- Byte 3: Y Coordinate
$03 should be seen as zero however, as any lower value than this will not be on the scroll on-screen
there are 7 possible rows which can be used for each scroll, so the maxium value of this byte should be $03+$07 = $0A, for the bottom row of the scroll.

-Byte 4+: Text in ASCII format.
Standard text data, continuing until either a $FC or $FF filled byte is reached.

After all data required for text layout is done, a single byte of $FF is used to terminate the scroll data.


When deciding which scroll is referred to in the map data, a standard reference number is used (as with switches etc), however, the starting point (i.e. which scroll is referred to by Reference 1) changes with each tower. I do not recall finding how this is determined from within the game-code... it must be somewhere though!

[MadMunky]

Currently searching though see if you have posted how stairs are done so I can move between levels

[osiris37]

Is there any programs in Windows I can use to read the non gif files?

I can't find where I got the .iff plugin for photoshop, it may even be native and installed from the download as standard as I'd not installed any new plugins in CS6, however I found this in my search, I havn't used it but it's free and can import/export .iff files:
http://www.xnview.com/en/features.html

This one does .iff & lbm too:
http://www.irfanview.com/

Edit: Forgot to say if you have .iff support in Photoshop you'll need to add the .iff extension manually on the end of the filename for it to open...

Hope this helps MM

[Hungry Horace]

Currently searching though see if you have posted how stairs are done so I can move between levels

stairs are dead easy .... just move an extra block in the direction you move onto it (if a hypothetical set of stairs was to be accessable from both directions, then you would still the extra square move in the direction you approach it from), and remember to allow for the "overlay" offset values for each level (contained in the level-data header) ...

holes are direct overlay locations. (i.e. if your offset values are correct, the two floors would be "aligned" when overlaid)



you may find this helpful:
http://www.ultimateamiga.co.uk/index.php/topic,8806.msg43133.html#msg43133

[MadMunky]

Currently searching though see if you have posted how stairs are done so I can move between levels

stairs are dead easy .... just move an extra block in the direction you move onto it (if a hypothetical set of stairs was to be accessable from both directions, then you would still the extra square move in the direction you approach it from), and remember to allow for the "overlay" offset values for each level (contained in the level-data header) ...

holes are direct overlay locations. (i.e. if your offset values are correct, the two floors would be "aligned" when overlaid)



you may find this helpful:
http://www.ultimateamiga.co.uk/index.php/topic,8806.msg43133.html#msg43133

Thanks I have the offsets working in my Map Viewer but I forgot about them, I was hoping I could just do (player.level = player.level++  or player.level--) and (player.movePlayerForward) but I guess I will have to remember how the offsets work now.. :s hope it wont take look long and I will then be able to move between levels and fall down pits..

Horace you get my email, let me know what you think im on MSN/G-Talk/Skype if you want to ask any questions.

[MadMunky]

http://www.xnview.com/en/features.html

This one does .iff & lbm too:
http://www.irfanview.com/

Found this this morning thanks, does the job Horace: You had so many images I need cheers.. I take it you never ripped objects on the floor from different distances? worth a shot