Jump to content
IGNORED

Hisoft basic users ?


Recommended Posts

By the power of the internet I have been reached. It will be a good excuse to get out my old STE and fire her up again.

 

The advanced GEM library you spoke of was called Enchant (http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=306622)

:D I was having problems getting anything working in the kit :(though maybe if that could be sorted out it would save a lot of trouble further down the line. HGT kit seems a bit of a mess so a replacement is more than welcome.

 

I haven't seem a manual for the commands yet, so maybe you still have it ?

Link to comment
Share on other sites

By the power of the internet I have been reached. It will be a good excuse to get out my old STE and fire her up again.

 

The advanced GEM library you spoke of was called Enchant (http://atariage.com/forums/index.php?app=core&module=attach&section=attach&attach_id=306622)

 

Hi Matt,

 

Good to see you around again. You are for sure better suited to advice exxos on issues that involves coding in hisoft basic any day of the week!

 

And furthermore, I think that any excuse that can bring an Atari out of the closet is a good one, so I'd say go with that :-D

 

 

Regards,

 

/Joakim

Link to comment
Share on other sites

RSRC_GADDR() is for most practical cases only ever used to find the address to the object tree(s).

 

 

dummy%=RSRC_LOAD(0,tree_index&,tree_adr%) ! The address to the object tree (tree_index&) is then stored in tree_adr%

 

 

ob_adr%=tree_adr%+obj&*24 ! Start at the address where object tree begins, move 24 bytes forward for each object you wish to "skip". This line of code locates the address of the individual object.

 

ob_spec%=LONG{ob_adr%+12} ! Essentially, 12 bytes into the individual object structure, you find the ob_spec field.

 

Then we should be able to use the concept previously described:

 

te_txtlen& = WORD{ob_spec%+24} ! Find the size of the text buffer attached to this object

te_ptext% = LONG{ob_spec%+0} ! Find the address to the text buffer

 

new_text$="Hello world" ! Find nice example text :-)

new_text$=left$(new_text$,te_txtlen&) ! Make sure it fits the available buffer

 

CHAR{te_ptext%}=new_text$ ! Update the text buffer with our brilliant example text (CHAR{} automatically adds en ending NULL byte)

 

dummy%=OBJC_DRAW(tree_adr%,obj&,0,form_x&,form_y&,form_w&,form_h&) ! Draw the updated object contents to screen. Last 4 parameters consist the clipping rectangle.

 

 

/Joakim

 

I still can't figure this out :(

 

When you have

 

ob_adr%=tree_adr%+obj&*24 ! Start at the address where object tree begins, move 24 bytes forward for each object you wish to "skip". This line of code locates the address of the individual object.

 

I get the tree addres using.

 

junk=rsrc_gaddr(0,info,tree&) Where info = 1 which is the main window form. It draws the window with all its objects so thats right.

 

 

 

obj, ok, so object, so I want to edit object INF_FORM1 which = 3

So it should be tree_adr%+3*24 in my case ?

 

So I actually have this..

 

obadr% = tree&+ (INF_FORM1*24)

 

Or

 

obadr% = tree&+ (3*24)

 

 

But it just says arithmetic overflow, so im stuck at "line 1" :(

Edited by exxosuk
Link to comment
Share on other sites

Not sure what is stirring up problems, but I have a hunch it may come down to the variable postfix type.

In GFA you will find this to be true:
Word & 2 bytes -32768 to 32767
Long % 4 bytes -2147483648 to 2147483647
In my example, anywhere a variable with postfix % is used, it refers to a LONG.
And when a & is used, it refers to a WORD.

I suspect the postfix types are not the same in Hisoft Basic.

From one of your lines of working code, I get that you can store the address of a tree in tree&. Hence postfix "&" must mean a LONG (4 bytes).
If that is correct, I would try to change the postfix of the variable you store the object address in:

obadr& = tree& + (3*24)


Regards,

/Joakim

Edited by gokmase
Link to comment
Share on other sites

I would have thought % would have been be pretty unbreakable, I was sure I read in the book % was long, but could be &=long, no consistency with anything :(

 

I have used the & and it gets past that error now, so I will try and convert over the rest of your example. Though I think this tedinfo & spec stuff is going to be the next trip point.

Edited by exxosuk
Link to comment
Share on other sites

obadr& = tree&+ (INF_FORM1*24)
obspec&=peekL(obadr&+12)
tetxtl& =peekW(obspec&+24)
teptext& =peekL(obspec&+0)

Now it says "Fatal address error" on the 3rd line. Man, this is hard work :?

 

tree& obadr& obspec&

1128266 1128338 1136375

Edited by exxosuk
Link to comment
Share on other sites

Then I think we have found at least one reason why the example fails.

My example was based on objects where OB_SPEC contains a pointer to a TEDINFO structure, as mentioned in post #19.

 

For a G_STRING object the OB_SPEC field however contains a pointer directly to the text to be displayed.

 

 

Regards,

 

/Joakim

Edited by gokmase
Link to comment
Share on other sites

xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 xxxxxx 0 GEM [Dialog Box: 0 [VDI Text: 0 VDI Te[xt Effects: 0 VDI [Small Text: 0 VDI [Graphics: 0 GEM [Window: 0 [Integer Division: 0 [Float Math: 0 [RAM Access: 0 R[OM Access: 0 B[litting: 0 VDI S[croll: 0 [Justified Text: 0 VDI [Enquire: 0 [New Dialogs: 0  0 Display: 0     0% 0     0% 0     0% 0 CPU: 0 Average: 0  0                 0  0  0 Time 0  0  0 Statistics 0  0  0 Ratio 0  0  0 Test 0  0  0 Reference 0  0  0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0  0  0 Reference 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0  0  0 System 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 0  GEMBench 0  File 0

So obspec& actually does seem to point to the object, I outputted from obspec& to 1,000 btyes and "xxxxxx" is the value. So could be a refresh type problem...

 

ahhhhhhhhh

BBBBBxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0 xxxxxxx 0

OMG!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

post-7597-0-58475400-1435873730_thumb.jpg

:-o :-o :-o :-o :-o :-o :-o :-o :-o :-o :-o :-o :-o :-o :-o

 

Its like a pre-alpha "hello world" lmao

Edited by exxosuk
Link to comment
Share on other sites

No, ob_spec is not pointing to an object at all, in this particular case it is pointing to the starting address of the text to be displayed.

To be accurate ob_spec is a field that is *part* of the actual object structure, not pointing to the object.

 

Depending on the object type ob_spec either contains:

 

1) A pointer to a TEDINFO structure (Object types: G_TEXT, G_BOXTEXT, G_FTEXT, G_FBOXTEXT)

2) A pointer to a BITBLK structure (Object type: G_IMAGE)

3) A pointer to a APPLBLK structure (Object type: G_PROGDEF)

4) A pointer to a ICONBLK or CICONBLK structure (Object types: G_ICON, G_CICON)
4) A pointer to a text buffer (Object types: G_BUTTON, G_STRING and G_TITLE)

5) A bit pattern (different for the respective object types) with various information regarding colour and borders, etc (Object types: G_BOX, G_BOXCHAR)

 

 

Regards,

 

/Joakim

Link to comment
Share on other sites

IIRC, issuing an OBJC_DRAW() for a G_STRING object will draw it in a transparent fashion, thus drawing the new (changed) text on top of the original one.

You could work around that (the transparency "problem") by instead drawing the root object but including every child object down to depth of 3 (needed in this example) and then apply a clipping rectangle in size of our object.


Something like this should work:

obj&=3 ! The object we are targeting...
ob_adr%=tree%+(obj&*24) ! Locate object address
ob_w&=INT{ob_adr%+20} ! Find out width of our object
ob_h&=INT{ob_adr%+22} ! Find out height of our object
dummy%=OBJC_OFFSET(tree%,obj&,ob_x&,ob_y&) ! Find out the absolute position on screen for our object
dummy%=OBJC_DRAW(tree%,0,3,ob_x&,ob_y&,ob_w&,ob_h&) ! Draw the root object (obj=0) and every child is contains down to max. 3 levels, limited by the clipping rectangle ob_x&, ob_y&, ob_w&, ob_h&

(I tested this against the GEMBENCH.RSC and you do need to set the depth in objc_draw() to at least 3 in order for the call to reach from the root object to the child object we are targeting in this example)


NOTE: The above is GFA-BASIC example code and as in previous examples, you will need to convert the variable postfixes to something better suited for Hisoft Basic :-D

Edited by gokmase
Link to comment
Share on other sites

ahhh, I was re-drawing, but I had OBJC_DRAW(tree%,3,10..... for some odd reason... I changed it to tree%,0,3 and got this...

 

post-7597-0-23327800-1435935874_thumb.jpg

 

This is awesome, this has taken ages to get text in that box!! lol Now I need to do my hello world, which involves some string to ascii value conversion :) Hopefully won't take many moments to program :) :) :)

Link to comment
Share on other sites

post-7597-0-71547000-1435942070_thumb.jpg

 

Finally...

 

Having a right old time with sub-routines, not sure why yet, so its hard coded in the drawing loop at the moment. Basically reads a string letter by letter , converts to ascii value and pokes into the text address. obviously I need to send a string and obj address to the sub routine, but like everything in hisoft, simple things which should work without any effort, turn into epics.

Link to comment
Share on other sites

post-7597-0-41438400-1435943998_thumb.jpg

*shrugs*

 

Seems on the second box it seems to be inserting text rather than overwriting it. Will add my debugging code back in to output to try and see whats going on now. At least the sub routines are working now, making some good progress today :)

Link to comment
Share on other sites

The size of the text buffers created upon RSRC_LOAD() are static, so beware of writing longer strings than those that are saved from RSC editor!
In your example:

Text buffer of object#3 can hold max 7 chars + null byte.
Text buffer of object#19 can hold max 6 chars + null byte.

First thing that happens if you write ascii chars past the limit of the buffer, is that you will trash the ending null byte, making it likely that you will find a longer text snippet than expected drawn to screen.
(Sending an ascii byte to obspec%+7 will thus trash the ending null for object#3 in your case.)
Writing further bytes beyond that limit will for sure cause corruption of any RSC data that follows the text buffer. Fun, fun ;)

Edited by gokmase
Link to comment
Share on other sites

Yeah I can understand the limits, I limited the strings to 6 letters each so nothing "overflows".. saying that.. your post made me double check and the ratio box is actually 1 letter smaller.. I will write a new sub and update the "time" boxes all at once and see if that works out ok... Yes endless "fun" this is :) thanks for your continued assistance :) I'm starting to wonder if your wrote TOS as you seem to know so much about it ;)

Link to comment
Share on other sites

I'm trying to refresh the object alone, but most of what it does if anything, is paste the text at the top left corner of the screen. It looks like the values for X & Y are not being returned correctly.

 

I get 0,0,56,16 for the object location and W & H.

obadr& = tree&+ (ob*24)
obspec&=peekL(obadr&+12)

	for n=0 to 6
	tt$=mid$(t$,n+1,1)
	xx=asc(tt$)
	pokeB (obspec&+n),xx
	next n

'GET INFO
w&=peekW(obadr&+20)
h&=peekW(obadr&+22)

junk=objc_offset(tree&,ob,x&,y&)


'UPDATE BOX
junk=objc_draw(tree&,ob,3,x&,y&,w&,h&)

The top part of the code works fine to show the "HELLO WORLD" text, so its the later part of the code "GET INFO" section which isn't working for some reason.

 

If ob=0 on the last line, then it just refreshes the whole screen after each text draw (though I forgot to set W,H,X,Y, so probably all zero in that test)

 

So not really sure whats going on now :-\

Link to comment
Share on other sites

My initial thought is that if objc_offset() fills in the return values for x/y with 0/0 then one of these things might have happened:

 

 

1) Something went wrong with the actual objc_offset() call. Either a problem with using wrong variable name for either input or output, or overwriting the variable data by accident somewhere in between the call and the evaluation of the data.

 

- Double check for typos on variable names! Also, verify that the returned value from objc_offset (stored in variable "junk" in your example) is filled with a non-zero value - if zero is returned then the objc_offset() call for some reason was unsuccessful.

- And as noted before, do pay attention to if a variable might be accidently overwritten before evaluated - that happens all too easy..

 

 

2) The object structure has been partly corrupted, and the area where its position is stored has been trashed. This is perhaps not that likely, but I suppose it could happen.

 

- Try and see if it makes a difference if you make the objc_offset() call *before* manipulating the contents of any string buffer.

 

 

3) The object has in fact been moved legally to a x,y-position that corresponds with absolute position 0,0. I don't find this explanation very likely in this case though.

A GEM program quickly gets very complex, and it is very easy to insert unwanted functionality by accident. Well, also known as a bug ;)

 

If we use the object #3 as an example, it is located inside object #2 that is a G_IBOX (probably used as a placeholder, to group together G_STRINGS, from obj #3 to obj #17, used for publishing test results).

The parent of object #2 is a G_BUTTON, object #1.

 

Now, if any part of the code alters the x,y-position of object #1 or object #2, this will of course affect the absolute position of object #3 as well.

That said, this scenario is maybe not the most likely one to be responsible here.

 

 

 

Regarding the redraw remark: In order to redraw the text without the transparency problem with the text, it is (as you noticed) not enough to redraw only the G_STRING itself.

You need to include at least the parents from object #1 with a depth=2 for this to look right I think.

 

(But for this redraw scheme to work as planned it is an absolute must to find out the correct (absolute) X,Y and width/height of the G_STRING object to use for the clipping rectangle in objc_draw, otherwise it will either redraw too much or too little.)

Link to comment
Share on other sites

I think you could be right, that it has to refresh the parent objects also. Even if I refresh "left box" it does not seem to refresh contents either. It only seems to work in refreshing the whole window (info). At worst I could just output the data all in one go, then just do a single refresh, rather than trying to refresh individual objects. Not very elegant if I only want to update a couple of boxes though.

 

I'm not sure why X&Y are returning zero. I'm not sure the W&H values are correct either. How did you work out what byte offset goes with W&H ? If I had a list to refer to of what is held at each offset then it may save some confusion later :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...