RE: A82: New Versions of CrASH...

[Prev][Next][Index][Thread]

RE: A82: New Versions of CrASH...


Comments inside :)

--

On Mon, 3 May 1999 23:59:30    CrASH_Man wrote:
>
>> >  -> VAT compatible Relocation of Programs
>> >  Allows using external data files by a running program
>>
>> Would this allow for absolute addressing in external files? Say, not ones
>> with just data for levels, but how about if I want to run
>> commands from the
>> external file, would the data need to be copied to an executable location?
>
>The programs will be found through a VAT search...  I may include a routine
>you can call to find a program within VAT.
>

Have you figured out how you're going to implement this yet? Will you search through the programs by name or what?

>> >  -> Several Newly added CrASH Calls:
>> >  CR_SpriteXOR ; draws clipped 8x8 sprite at GRAPH_MEM
>> >  CR_SprHtChg ; changes sprite's height
>> >  CR_GRBClear ; clears GRAPH_MEM - suggestion from Kouri
>> >  etc.
>>
>> Sounds alright, but I guess you decided not to go with the X by X
>> sprites,
>> and does the "CR_SprHtChg" routine change the "X" in an "8 by X"
>> sprite?  I
>> never did get that answered... =P
>
>Sorry, but X by X requires tremendous overhead, and I don't think I can go
>on writing an extremely optimized one.  I do, however, already have a very
>quick 8x8 sprite routine at my disposal along with its sprite height changer
>so I thought I might want to stick with that.
>

You mean an x by 8 sprite xor routine right? Not an 8 by 8 routine.

>> >  -> Macros for some op-code combinations
>> >  LD_HL_BC, NEG_HL, etc.
>>
>> I think I understand that Macros have the Compiler just copy that
>> section of
>> code into spots of the code whenever a referrence is made to that Macro.
>> However, does this save space? Why not just include these two
>> routines and
>> "etc" as subroutines within CrASH?
>
>Well, some macros take up the same space or a negligible amount over the
>number of bytes required to simply do a CALL.  (like 2 to 5 bytes, and CALL
>is 3 bytes) The extra CALL/RET combo requires 27 clocks, so for
>speed-sensitive code, I thought it would be better to use macros.  I do plan
>to have other macros too, like ADD_HL_A, and CMP_HL_DE, and the like.
>

Macros are cool. :)
#define text(x,y,string) ld hl,256*x+y \ ld (GRAF_CURS),hl \ ld hl,string \ ROM_CALL(D_ZM_STR)
Like basic :)

>> There's a small routine I use in my 83 programming that I find useful, so
>> maybe its worth putting in, i dunno... When getting direct input from the
>> keypad, the keyport value can be loaded into B, a call made to
>> this routine,
>> and the value in A checked upon returning from the subroutine...
>>
>> Direct_Input:
>>        ld a, 0ffh
>>        out (1), a
>>        ld a, b
>>        out (1), a
>>        in a, (1)
>>        ret
>>
>> This subroutine seems useful to me, that if a programmer was reading from
>> many different keyports this repetitious code would not have to
>> be included,
>> which saves bytes in programs. Perhaps more people could use this
>> technique,
>> but perhaps it isnt signifigant enough to include. Whatever you
>> think, just
>> giving some suggestions... cya. =P
>
>Actually, I use a similar technique, though that should not be a call, as I
>explained above with the macros.  I guess I can include it though, as some
>people may find it useful.
>
>-crashman
>

Uh, I'm worried that CrASH will get bloated with routines that seem kinda cool but won't be used all that often. Maybe you're just better off making #include files whenever you think up a good useful routine.


HotBot - Search smarter.
http://www.hotbot.com