English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. Blitz Basic

 
 
Thread Tools
Old 18 August 2017, 14:42   #121
E-Penguin
Banana

 
Join Date: Jul 2016
Location: Darmstadt
Posts: 661
Quote:
Originally Posted by Daedalus View Post
In the original Blitz 2.1, you still need to specify a maximum size, so

Dim List Things.l(200)

allocates enough memory for containing your list with 200 items in it, even though it contains 0 objects. They're still "dynamic" in that they only show the number of items you put in, but you'll get crashes if you go above the maximum.
Could create your own linked list implementation though, with a NewTypes containing the thing you want and pointers to the previous/next (or some START/END placeholder)?

Code:
NewType .thing
    name.s
End NewType

NewType .thingListItem
    myThing.thing
    *some_pointer_thing_here.thingListListem
End NewType
and so on.

I'm getting ready to dive into Blitz Basic and will have endless questions coming over the weekend. Watch this space.
E-Penguin is offline  
Old 18 August 2017, 19:16   #122
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 3,638
Are you sure you can do that?
idrougge is offline  
Old 18 August 2017, 19:43   #123
E-Penguin
Banana

 
Join Date: Jul 2016
Location: Darmstadt
Posts: 661
Not at all sure. Hence the question!

Well, I would do it in c but that's a boring language. Every man and his dog does c.

I think pointers are stored as data.l so perhaps the pointer needs to be cast to / from the appropriate NewType. Is casting a thing in Blitz Basic?
E-Penguin is offline  
Old 19 August 2017, 00:18   #124
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
You can just store the pointers as longwords in Blitz and they'll work fine. Pointers are broadly the same in Blitz as in C, but there are subtle differences in their implementation. You can define a pointer in a Newtype, but you access it without the *, so for your example you would access your link pointer as:

*nextItem = MyVariable.thingListItem\some_pointer_thing_here

The awkwardness comes from actually creating the items, which I think will have to be allocated in memory manually and then assigned to a pointer when that item is required. You can use SizeOf .thingListItem to get the size of the allocation, and use the standard exec memory routines. It should be relatively doable as a set of functions that you could put in an include is you wished to use them in multiple programs.
Daedalus is online now  
Old 19 August 2017, 01:05   #125
Cylon
Registered User

 
Join Date: Oct 2014
Location: Europe
Posts: 466
@E-Penguin
Yes, you can do those things with BlitzBasic2.

There are caveats, of course.

here is an example:

It creates a list of titem and then adds the first node, then another. And links them together to a ring-like structure.
Code:
NEWTYPE.thing

  data.w

End NEWTYPE

NEWTYPE.titem

  ola.thing

  *nxt.titem

End NEWTYPE

Dim List exmpl.titem(10)


NPrint &exmpl(0) , " >> ",exmpl(0)\nxt
NPrint &exmpl(1)

If AddLast (exmpl())

  root.l= &exmpl()

  Print    root , " >> nxt ="

  exmpl()\nxt = root ;or 0 to end this

  NPrint   exmpl()\nxt

  store.l=exmpl()\nxt

  If AddLast (exmpl())

    Print    &exmpl(), " >> nxt ="

    exmpl()\nxt = store.l ; or root or 0 to end this

    NPrint   exmpl()\nxt
  EndIf

EndIf

NPrint "SizeOf thing : ",SizeOf.thing
NPrint "SizeOf titem : ",SizeOf.titem

MouseWait

End
Here is one tricky thing: In the example above you can see me using an index value for accessing list items. This is not (really) working in BB2. At least, it works until you change the list items somehow. then everything gets newly allocated and the index's points to ... somewhere. So don't do that. Even if it works somehow sometimes.

Pointers are casted and treated as LONGs, but you have to take care for yourself to not free a pointer to something or refer via a pointer to an address without veryfying the address. Blitz will also try to cast ANYTHING to ANYOTHER without telling you. Your job, Coder (well, you might get compiler errors, syntax errors, overflow errors - make the best of it).

Last edited by Cylon; 19 August 2017 at 01:27.
Cylon is offline  
Old 03 September 2017, 11:29   #126
E-Penguin
Banana

 
Join Date: Jul 2016
Location: Darmstadt
Posts: 661
Sprite Multiplexing - what is it and how can you do it in blitz2
E-Penguin is offline  
Old 03 September 2017, 14:10   #127
Cylon
Registered User

 
Join Date: Oct 2014
Location: Europe
Posts: 466
You have only 8 sprites in hardware to display, so called sprite channels.
If you want to display more sprites than 8, you have to reuse the channels multiple times.

so, lets say you display one sprite in the upper part of the screen. a couple of milliseconds later the video hardware has passed that part of screen and therfore already displayed this sprite. Now you can use this channel to display another sprite lower on the screen, where the screen has not yet been drawd.
Cylon is offline  
Old 05 September 2017, 00:02   #128
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
Blitz includes a DisplayLibrary command that sets this up in the Coplist for you, though I've never used it myself. Check out the CustomSprites command, bearing in mind that you'll need to add the desired value (4*number of sprites + 2) to the Custom space in your InitCopList line. This gives you a second use of each of the eight sprite channels, with channels numbered 8-15 instead.
Daedalus is online now  
Old 23 October 2017, 03:34   #129
Cobe
Registered User

 
Join Date: Jan 2014
Location: Belgrade / Serbia
Age: 35
Posts: 595
Ok, guys, is it just too late or AGA dualplayfield playfield 2 by default uses colors 8-23??

I'd say it is. Had to set bplcon3 bit 12-10 to 100 with displaycontrols 0,0,$1c00,0 now its 16-31.

Last edited by Cobe; 23 October 2017 at 04:31.
Cobe is offline  
Old 23 October 2017, 13:28   #130
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
By default the AGA dual playfield display uses colours 8-23 because that is compatible with ECS, which uses 0-7 for the first playfield and 8-15 for the second. As you point out, bits 10-12 set the pen offset of the second playfield, with %000 being no offset (starts at 0), %001 being 2, %011 being 8 (default ECS mode), all the way up to %111 being 128.
Daedalus is online now  
Old 09 October 2018, 20:19   #131
amyren
Registered User

 
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 6
I have been looking for an example code on how to display an image. I have looked at the image.include.ab3 but I find that a bit confusing trying to work out what parts of that code I need.
What I would like to see is an example on eg. how to load an iff file and display it inside a window on the workbench.
amyren is offline  
Old 09 October 2018, 22:48   #132
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
If you're using AmiBlitz3 and the image.include.ab3 code, you simply load the image with image_Load{} and then blit it to the relevant rastport, which is part of the window you would like to use (this can be skipped if it's the currently used window). This can be opened with the standard Blitz commands, or with the AmiBlitz Window include.

It will look something like this using the image include and the standard Blitz window commands:

Code:
Optimize 5
XINCLUDE "image.include.ab3"

WbToScreen 0

If image_Load{0, "sys:prefs/presets/patterns/Amiga Waves.jpg"}
  wid.w = image_GetWidth{0}
  hei.w = image_GetHeight{0}
  *mywin.Window = Window(0, 100, 100, wid+10, hei+20, $140E, "Image Test", 1, 2)
  If *mywin
    image_Blit{0, 0, 0}
    Repeat
      ev.l = WaitEvent
      Delay_ 2
    Until ev = $200
  Else
    NPrint "Error opening window"
  End If
Else
  NPrint "Error loading image"
End If

End
You might have to add all.res to the residents list if you get an error saying Type not found or similar.

Edit: If you use image_Load{}, it loads the image using datatypes, so IFF, JPEG or whatever isn't a problem.

If you're using native screenmodes, the older method is simply to use LoadShapes to load the image, then WBlit to blit it to a window. Note that this method only works with IFF files, and will crash if it can't load the specified file.

Last edited by Daedalus; 11 October 2018 at 00:11. Reason: Fixed code!
Daedalus is online now  
Old 10 October 2018, 22:12   #133
amyren
Registered User

 
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 6
Thanks for the reply.
I did try compiling that, first it came up with the error message that newsyntax was needed and was hinted to put optimize 4 at the beginning of the program.
So I did insert Optimize 4 at the top of the code, now it gives a compile error from line 2 (which is the line where the xinclude image.include.ab3 is) that the if block is to big.
Possibly wrong code begins here: ny
At this point it will also have opened the image.incude.ab3 and the cursor at line 1403

I was not sure what to do about this, so I tried to increase string buffer size and stacksize in compiler settings, but as expected this did not help.
And, I do have the all.res as resident.
amyren is offline  
Old 11 October 2018, 00:00   #134
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
Ugh, sorry about that - I typed it from memory without trying it. To be fair, I can't see why the hell it's giving that error, it's only a simple bit of code, and only yesterday I used image.include to blit an image in a window. I'll check it out...

Edit: Yep, it's doing the same thing for me too... And I've no idea why, but it works if you use Optimize 5 instead of 4. All that is is integer optimisation, but I guess it changes something with memory allocation or something that lets it work. I've updated the example anyway so that it's now known good code. Again, sorry about that!

Last edited by Daedalus; 11 October 2018 at 00:08.
Daedalus is online now  
Old 11 October 2018, 11:20   #135
amyren
Registered User

 
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 6
Thank you very much. Yes, that works here too
I guess that optimize 5 equals optimize 4 + 1, so that switches on both integer and newsyntax.

I will do some experiments with this code now. I do notice that it will require the ab3zlib.library to run.

I have used AmiBlitz3 for teaching myself a bit basic here. I find the editor easier to work with than Blitz2. But I have been adapting my program so that it also will compile in Blitz2.
My idea behind that is that when the program is finished it should work on any Amiga without FPU , + newgen if possible. (I do use gadtools so I guess WB2 or 3 will be required as minimum.)

As image.include.ab3 is for AmiBlitz, I guess I must find another way to do this in Blitz2.
Is that loadshape and wblit the answer then, and will that work also will RTG?
Also if I stick to only iff images, could I get it to work as a standalone program without the need of any zlib's?
amyren is offline  
Old 11 October 2018, 11:34   #136
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
Quote:
Originally Posted by amyren View Post
I guess that optimize 5 equals optimize 4 + 1, so that switches on both integer and newsyntax.
Yep, that's it. Using numbers like 5 is a shortcut, but ultimately the argument is a set of binary flags. Bit 0 is the integer optimiser (value=1), bit 1 is the FPU optimiser (value=2) and bit 2 is the New Syntax option (value=4). So adding them together activates the relevant bits in the same way as a bitwise OR operation would.

Quote:
I will do some experiments with this code now. I do notice that it will require the ab3zlib.library to run.
I believe zlib is only required for using PNG images directly. The jpeg.library is used for JPEG files directly, but you can also modify some flags at the top of the image.include.ab3 file to disable their use, in which case you can still use datatypes without extra libraries.

Quote:
I have used AmiBlitz3 for teaching myself a bit basic here. I find the editor easier to work with than Blitz2. But I have been adapting my program so that it also will compile in Blitz2.
Indeed, AB3 is a much nicer environment for development.

Quote:
My idea behind that is that when the program is finished it should work on any Amiga without FPU , + newgen if possible. (I do use gadtools so I guess WB2 or 3 will be required as minimum.)
GadTools is available for OS 1.x too, but isn't included as standard so it complicates things. There are also Intuition gadgets that will work on standard 1.x too, but they're pretty primitive and not particularly nice to use.

Quote:
As image.include.ab3 is for AmiBlitz, I guess I must find another way to do this in Blitz2.
Yeah, for now anyway. A while back I started backporting the AB3 includes for use in Blitz 2.1, but have only done a few that I needed for a particular project (and even they aren't complete yet). It's actually kinda tricky since they use a lot of AB3-only features that need to be worked around. Perhaps some day...

Quote:
Is that loadshape and wblit the answer then, and will that work also will RTG?
Yes, it should in theory anyway. If you do the coding in AB3, it will highlight any commands that use the custom chips directly in red, and this will let you know things that are likely to cause problems on RTG and NG systems. LoadShape and WBlit are system-friendly, so they *should* be ok. I suspect there may be palette issues on high- or true-colour screens though. But no harm in trying.

Quote:
Also if I stick to only iff images, could I get it to work as a standalone program without the need of any zlib's?
Yep, see above. You can disable the requirement and still use datatypes to use any image format with image.include.ab3, but you lose out on some extra features like alpha channel support and so on.
Daedalus is online now  
Old 11 October 2018, 14:27   #137
amyren
Registered User

 
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 6
Quote:
Originally Posted by Daedalus View Post
Yes, it should in theory anyway. If you do the coding in AB3, it will highlight any commands that use the custom chips directly in red, and this will let you know things that are likely to cause problems on RTG and NG systems. LoadShape and WBlit are system-friendly, so they *should* be ok. I suspect there may be palette issues on high- or true-colour screens though. But no harm in trying.
Oh, so thats why certain commands did turn red.
No wonder my timer commands did not work when testing it on MorhOS.
Is there another way to implement a timer without using custom chips?

Quote:
Yep, see above. You can disable the requirement and still use datatypes to use any image format with image.include.ab3, but you lose out on some extra features like alpha channel support and so on.
I found that there was quite a lot to be disabled to get rid of the ab3zlib

I did comment away shamelessly every part with have zlib references and I also removed any PNG references. I might do the same with jpeg as well, since I probably will use only iff.

I think that image.include.ab3 file is much bigger than needed. I think that the demo-code could be removed and put in two different files.

Using my now image.include_mod.ab3 file does reduce the size of the executable by 23kb.
And if I use include instead of xinclude I would save another 83kb. In total the executable goes from 285kb to 179kb.
What is the difference between xinclude and include?
amyren is offline  
Old 11 October 2018, 16:26   #138
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
Quote:
Originally Posted by amyren View Post
Oh, so thats why certain commands did turn red.
No wonder my timer commands did not work when testing it on MorhOS.
Is there another way to implement a timer without using custom chips?
The OS-friendly way is to use timer.device, which is also a safer way of doing it than the Blitz way of directly accessing the CIA hardware, which may or may not already be in use elsewhere... AB3 has two timer includes that can be used, depending on your needs. gtimer.include is intended for GUI timings, and it can create signals to wake your program up at specified intervals. Kind of like a custom version of IDCMP_INTUITICKS events. The other is eclock.include, which is more like a count-up timer. It has high resolution and low resolution options, high resolution uses more CPU time but gives very accurate results for things like benchmarking file access etc., and resolution is better for timing longer operations like a 3D scene render.

I'm not sure if there's an easy way of using Blitz 2.1 commands - there may be some suitable commands in a 3rd party library, but I can't think of any right now. Otherwise, you can use timer.device directly in the same way as a C program would. The process is quite involved, but I'm sure there are plenty of C examples around for it that could easily be translated into Blitz.

Quote:
I found that there was quite a lot to be disabled to get rid of the ab3zlib

I did comment away shamelessly every part with have zlib references and I also removed any PNG references. I might do the same with jpeg as well, since I probably will use only iff.
Hmmmm, I was sure there was a flag you could set to disable all zlib functionality. I'll have to look into it...

Quote:
I think that image.include.ab3 file is much bigger than needed. I think that the demo-code could be removed and put in two different files.
Yeah, the demo code is pretty big, but it doesn't actually get included in the final executable (there are CNIF...CEND compiler directives surrounding it so the compiler ignores it if it's been included), and is often useful for testing an include.

Quote:
Using my now image.include_mod.ab3 file does reduce the size of the executable by 23kb.
Yep, that's a good approach. If you really wanted to, you could even create custom includes for every program that you write, containing only the procedures and declarations you actually need. It's a lot of effort though...

Quote:
And if I use include instead of xinclude I would save another 83kb. In total the executable goes from 285kb to 179kb.
What is the difference between xinclude and include?
That's very weird... XInclude is the same as Include except it only includes the requested file once, whereas Include will include it twice if it's used twice. It's bizarre that you're seeing that difference - if anything, Include should produce *larger* executables (and compile errors due to duplicated procedure labels). Are you sure you didn't change anything else in between, like turning off the debugger?

AB3 does produce large executables unfortunately, but there are also other things that affect the executable size and might help. First, disable the debugger before you create an executable. That stops it including a lot of extra trap code and so on that the debugger uses, but has no use in executables (and can even cause crashes in some cases). Second, once you've created the executable with Create executable... Use the Create Minimized Executable menu option instead to make the compiler take more passes and eliminate some unused code, but beware it will overwrite the previously created executable without warning. This takes a lot longer though so probably only necessary when you're ready for your final build, but you might find it makes a similar reduction in size as removing the unused parts of your includes.
Daedalus is online now  
Old 12 October 2018, 22:14   #139
amyren
Registered User

 
Join Date: Sep 2018
Location: Elsfjord / Norway
Posts: 6
Sorry, I think I must have have them swapped. Now when I tried to re-compile those with include and xinclude, it is clearly the x that makes the smaller executable.

I did a rewrite of the example to get it to load an iff using BlitzBasic2
It works but the colours looks terrible. I have not experimented with palette settings yet, could you advise me how I can adjust the colour output?

Here is the bb2 compatible example:

WBStartup
WbToScreen 0

If Exists("sys:test.iff")
LoadShape 0, "sys:test.iff"
If Window(0, 100, 100, 120, 140, $140E, "Image Test",1 ,2)
WBlit 0, 0, 0
Repeat
ev.l = WaitEvent
Delay_ 2
Until ev = $200
Else
NPrint "Error opening window"
End If
Else
NPrint "Error loading image"
End If

End
amyren is offline  
Old 13 October 2018, 14:44   #140
Daedalus
Registered User

Daedalus's Avatar
 
Join Date: Jun 2009
Location: Dublin, then Glasgow
Posts: 3,283
The palette issue is likely to do with Blitz not really understanding RTG, resulting in blitting without colours being taken into account. I'm not entirely sure of how to get around that with the standard commands, or if it's even possible.

The Mildred library is apparently quite good at dealing with chunky-format graphics operations (I believe it was used for the game Foundation), but I haven't used it myself so I can't say much else about it. From a quick look at the documentation it looks a little more involved than the standard commands.
Daedalus is online now  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
[blitz basic] How much amiga-blitz friendly is this? saimon69 Coders. Blitz Basic 104 29 November 2016 20:45
Blitz Basic (1) Retro1234 Coders. Blitz Basic 9 18 February 2016 17:54
Blitz basic 2 Help Havie Coders. Blitz Basic 30 08 September 2013 09:15
Blitz Basic 2 anyone? jobro request.Apps 12 28 November 2005 18:15
Blitz Basic 2 LaundroMat Retrogaming General Discussion 5 24 July 2001 08:10

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 11:39.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.13200 seconds with 16 queries