Response to Mark (cont. "DrawText 'Glitches'")

I ain't mad 'cause the thread was locked- it wasn't a bug in the end, so it was neccessary. I'm just continuing this so I can answer your questions, Mark.

Now let's begin..



Yes, actually, because you decided to 'screw up' (in my book) DrawImageRect. Think I was happy about having to write my own procedures to draw portions of textures? No. But I had to because you decided to go with a different implementation instead of, oh, I don't know, maybe sticking to what you already had?

Let me explain what I mean- this is the old DrawImageRect:


This is the new DrawImageRect:


Notice the two missing arguments? Yeah, those're the ones that screwed me big-time. So now I use my function:


So now I have a function that does everything. It draws a portion of an image with variable width and height, and since all gadgets in my GUI's control/gadget/widget skins are on the same texture. So I have to be able to draw portions of textures or split up my control skins into about 9 pieces per control.

So if you can give me a function that allows me to draw a portion of an image (a DrawImageRect(Image:Object,X%,Y%,W%,H%,Rect_X%,Rect_Y%,Rect_Width%,Rect_Height%) is all I need- and I think we both know how easy that is to write- in fact, if you guarantee to include my code to do that, I'll write it for you), I'll be set.

Even so, if I wanted to make my code work with only Max2D stuff, you'd have to provide me with a SetupOrtho() function, 'cause otherwise I have to use API-specific functions.

I would very much like the suggested new function as well. I can't make my Bmax Fontext module without it or until GL is much safer to use.

Why didn't you write your own with SetViewport, at least as a temporary measure? Where is your original feature request or bug report with respect to DrawImageRect?

Why are you getting so worked up when you unwisely tried to mix GL and Max2D (when there was a far simpler solution to your problem) and it didn't work out?

It's in the 'implied' bin, 'cause when Mark decided to almost all of the old 2D Blitz commands, I expected he would attempt to make them all the same. Wrong was I. Frankly, relying on Mark to do something is far less viable than writing my own function and forgetting about the inadequacy. But now that the DrawText glitch seems to come from using GL, I'm asking for an 'official' implementation of what was already in Blitz3D/Blitz+/[and probably ]Blitz2D.



Care to explain this far simpler solution? SetViewport? That isn't simpler, that's a hackjob of a workaround- actually, I think workarounds are hackjobs. Now my code- that is far simpler.

No, it's not.


I'd not call it a hackjob of a workaround. At all. It would work, and you wouldn't have the problems you're having right now. Calling OpenGL commands directly interlaced with Max2D calls - now THAT is a hack job.

Considering GLMax2D uses those same commands, I don't consider it a hack job. I consider it adding what isn't already there.

!?!!!
GLMax2D is built around assumptions and rules on when it calls certain GL commands. Circumventing it to call GL commands directly is, basically, the biggest hack job you can have.

I think I understand your perspective on that now.

On another note: how come you never come on IRC anymore? I THOUGHT WE HAD SOMETHING!

Noel, don't you think it might be better to ask politely for feature requests rather than constantly sniping at the person you'd like to implement them?

What if at some point it is extended to include an option to compile for DirectX on Windows instead?

In such a situation you would have shot yourself in the foot by hardcoding API-specific things rather than sticking to the 'generic' non-API specific commands

I think it would be a pretty handy function to include in the Max2D feature set. This is how you can do it at the moment:

Function DrawImageRect2(img:TImage, x#, y#, rx#, ry#, rw#, rh#, frame=0)
	Local vx, vy, vw, vh
	GetViewport(vx, vy, vw,vh)
	
	SetViewport(x, y, rw, rh)
	DrawImage(img, x-rx, x-ry, frame)
	
	SetViewport(vx, vy, vw, vh)
End Function

But this draws the entire image but is scissor tested so it doesn't draw all of it. IMO a cleaner way would be to draw a rectangle of the correct size and modify the texture co-ordinates at the corners.

Nice contribution teamonkey. I will certainly use that for starters.

Noel does need to calm down. :)

Well it would be nicer if the image system was augmented with a UV based loadanimimage, Ie pass an array of uvs to LoadAnimImageUv(url,uvs[],flags). So its all handled silently, and you can still call drawimage image,x,y,frame, but it would just use the uvs stored to reference part of 1 image, rather than the seperated frames.

When 99.9% of my requests, e-mails, questions, etc. are ignored then you've lost my interest in being 'polite'. 99.9% being an exaggerated percentage, but considering how little Blitz Research seems to listen (god forbid that happen) to their users, it's not too far from the truth where the community on a whole is concerned in my opinion.

Mark: Turn off your spam blocker, the bit where it deletes anything related to Blitz and/or myself is starting to become annoying.

As I said, if you can guarantee that my code would be included, I would personally write the code to 'fix' these 'problems' myself.

I agree with Noel on this one. There's no reason to have a 2D drawing API that doesn't have the ability to draw sub sections of an image. Especially when the preceding API -had- that feature.

That's almost as insane as shipping a game programming language without a GetKey() implementation.

Burned.

C'mon, getkey is not THAT important and it is now available.

Yes, it is.



Only after everyone complained. The point is, Mark released BlitzMax to the public (before you can say 'but you use the Win32 beta- that's not a public release', let me remind you of the existence of the Mac version) without some things which you really do need in a games programming language- and some things that just make programming languages in general better (properties, overloading, multiple inheritance, unsigned data types, etc.).

> The point is, Mark released BlitzMax to the public

With a free 30 day demo. He didn't "force" anyone to buy the product without trying it first. For the windows coders out there (myself included), we have only ourselves to blame if something is "missing" from blitzmax - since we individually decided to buy a product before we could try a demo of it.

Yes please!

Wrong, we're to blame for buying it. Mark 'n' co. are to blame for anything that is 'missing'.

Noel, email me to arrange a refund if you really consider it to be that bad. Alternatively, you could wait until it's out of beta and benefit as more features are added in time. Just don't ruin our forums by attacking us non-stop because your personal requests aren't being immediately added.