SyntaxBomb - Indie Coders

but I think I read here that BMax had a fault when dealing with FP numbers?

I've not noticed any but I'm curious to what it was.

Jim

As a general rule CPUs don't handle floating point calculations with the same precision as integer arithmetic. Mostly due to the inability to represent decimal numbers precisely with binary values.

I guess it was me, who wrote this.

I detected this, when I was transfering my FFT-Algo from BlitzMax to BlitzMax Ng. The results were completely nonsense, when I run the same code on BlitzMax NG.

https://www.syntaxbomb.com/blitzmax-blitzmax-ng/precision-bug-in-blitzmax-ng/

This happened with the old version 0.129, which was the main RELEASE for a long time before 2023. After an update to current version 0.136 the problems are solved now.

This became the moment when Brucey also replaced the official RELEASE on the BlitzMax's homepage with V 0.136.

Thanks.

Hi, sorry to bring up an old thread but ....

I'm doing sprite rotation code on a pixmap and I was getting some funny timings - different angles were taking double the time other angles were. The angles were random and the position on screen random.

So, I thought I'd install 0.136 and everything is correct. Same times and about 5% faster. (So, definitely fixed.)

I had a few MAV until I realised 'width', 'height', 'time' were now keywords. (Are there anymore new ones?)

Also the way to get an int ptr to a pixmap is now :

Screen_Pixels:Int Ptr = Int Ptr(PixmapPixelPtr:Byte Ptr( Screen_Pixmap:TPixmap))

Anyway, glad it's all working.

Cheers, Jim.

hi JBR. i like to run the bleeding edge (right now 0.143) saw some people talking about some pixmap work in the discord possible updates made to it recently.

width, height, time - are no keywords.
Why do you think that?

Anyways - yeah, the "convenience function naming scheme" (your procedural interface - like "DrawImage") consists of a lot of "common names" which limits you a bit regarding variable names ... think of "field textheight:int" vs "TextHeight()". But this was the case in vanilla already - we just extended things a tiny bit to "keep things the way they were". I myself would prefer more "scoping" (font.GetTextHeight() etc).

QuoteScreen_Pixels:Int Ptr = Int Ptr(PixmapPixelPtr:Byte Ptr( Screen_Pixmap:TPixmap))

Screen_Pixels:Int Ptr = Int Ptr(PixmapPixelPtr(Screen_Pixmap))looks shorter to me (no need to append the ":type" each time except for constants like "1:Double" which is required in array-predefinitions ([1:double, 2:double])
But - why an int pointer? The data is "bytes" - and the "interpretation" depends on the color format of the pixmap. So if it uses 4 bytes (PF_RGBA8888, PF_BGRA8888) or only 1 byte (pf8 for example). (See pixmap.mod/pixmap.bmx - ReadPixel())
I assume you have only argb (the internal color format of the pixmaps which are RGBA8888 or BGRA8888) and want to get "one pixel" at a time? Ensure you only use it for "rgba" pixmaps (rgb + alpha, not just RGB or just A or monochrome ones) then. Else you might see odd results.





@ William
About what "possible updates mate to it recently" are you talking? I am not aware of changes to pixmap functionality.



bye
Ron

Hi Derron,

Maybe not keywords, but I was using them as variable names and this is not allowed as they are highlighted now.

Need 4 bytes per pixel, hence int ptr.

I'm not sure but the Alpha byte in a pixmap may not do anything?

Jim.

highlights ... maybe some module is using it somewhere. Maxide only highlights what it is told to highlight - no matter if it is allowed syntax or not, or a registered keyword.


The alpha byte:  if you render an image with alpha channel after you set the blendmode to alphablend ... then it will be (semi-) transparent (0 = absolutely transparent, 255 = fully opaque). When rendering "pixmaps" (DrawPixmap) I think it is ignored. But if you "DrawImage(LoadImage(thepixmap))" it should be visible.


bye
Ron

BlitmaxNG works a treat!

JBR, Sounds like you have a good grasp already. You wont be disappointed with BlitzmaxNG if you persevere with it's "Superstrict quirks" and pay particular attention to Byte's, int, Double's,  Size_T etc..

The only thing with it is FIRST TIME COMPILE. It takes 10 mins after that almost instant!

Superstrict is a must to get fastest code. However you have a lot or pre-written commands, written in a specific way to be used properly. So you need to be spot on with byte, int, float etc..

or you will get random things happening or not happening.

Ive learnt how to use BlitzmaxNG and it's first class. And ive only scratched the surface with it's capability's. And my Knowledge!  

The Biggest problem is the lack of detailed documentation examples on how to use each individual command. Who ever did this side gave up or wasn't paid enough for the task at hand!?

I find when something goes open source it's usually it's down fall. It gets tweaked and pulled, not necessarily for the better. And even ends up as something identical. Why?

I understand Brucey is re-visiting Blitz 3D. Why?

Ive tried them all and BlitzmaxNG is the best it has a very nice syntax to get to grips with. 

I know a very talented programmer who gave up on BlitzmaxNG and moved onto something else. SHAME!

If you wright code in normal Blitzmax you can make lots of error's and it's very forgiving. You will pickup bad habits.

If you change to BlitzMaxNG you will be frustrated to hell. Because of the bad programming habits you've picked up! That's my own personal experience with learning with it.

So Brucey if your reading this, Please make BlitzMaxNG your focus May be BlitzMaxII. And ask people who are learning and using it, there wants and wishes. To make that perfect Language. Id gladly pay good money for it.

Kind Regards Baggey