Float Positioning Blit Images

[Jamiro]

Hello,

I've been using blit function to emulate a HUD, but it seems it only use integer-based coordinates which can lead to an aliased animation while positionining when the values are decimal, so for example if I have a point in screen that has a coordinate of 1,5x; 10,8y, it would need to be round or truc to its integer value thus leading to rough representation when these values tend to change.

So my question is, is it possible to have a blit with decimal based coordinates? The only solution I've came up so far is using an object in space coordinates and constantly project its coordinates onto a parallel plane to the screen using Interact2D which could reduce performace exponentially much more than using blit. Is there any other good and correct way to do this?

thanks

[EgonOlsen]

Well...that the blit() methods take integers only is caused by the software renderer. It can't do subpixel-blitting and the methods reflect that. It's not as easy as it might look at first glance to change this now. To make me understand this better: What kind of HUD is that? Why exactly do you need floats to blit it?

[Jamiro]

Ok, so there's a reason why it can't, but...

Couldn't it be done using a simple condition inside the blit method that checks if it's using Software or Hardware and depending on which context is being used it switched to either an integer blit or float blit (while changing only the outside parameters to be of Float type thus keeping retrocompatibility)?

I'm currently making progress bars and 2D-point indicators. When the progress bar increases or decreases the effect is too sharp when its changing by small units, so it its not as smooth as if I were to use a space sprite. It also happens when using dots on a grid, if I change a dot a very small increment in position it will not have a smooth change, it will be moving as if it were painted like a bitmap raster, instead of a smooth raster.

like the example below illustrates a change of position of a sprite's pixel:

1- integer positioning mode:


2- float positioning mode:


is it possible to update the blit method to satisfy both rendering modes while keeping it's legacy?
If so it would give a more accurate way of making smoother animated UI components.

[Jamiro]

Do you think it is possible to add this change or is there any other way I can obtain this result?

[EgonOlsen]

I'll have a look...

[Jamiro]

Is it also possible ATM to rotate any blit image? If I wanted to add any HUD element that uses rotation around any given pivot, like a 2D sprite, is there any way to do it? If not so, is it possible to add it in a near future?

[EgonOlsen]

No, it's not possible but you could use an Overlay instead.

[Jamiro]

Hello, any news about this possibility to add a decimal coordinate system for blitting?

thanks

[EgonOlsen]

Sorry, seems like I've forgot about it. I remember looking at it, but I can't remember the outcome. I'm on holidays ATM, but I'll look at it again once I'm back.

[Jamiro]

Sure, no worries, take your time

[Jamiro]

Hello,

getting back again on this matter, the outcome was because on Hardware Renderer we can blit with a floating coordinate system, whereas in the softwre renderer we can't, but we could use floating type for both and then just use the float point for hardware and cast to int on the software renderer, thus having the legacy code running well keeping compatibilty. I think that was the feasable idea behind this whole conversation.

lemme know if its possible to do or not,

many thanks,

[EgonOlsen]

Yes, that should work. I'll try to add it in the next few days.

[AGP]

And software-rendered Polylines, please?

[EgonOlsen]

That's a whole different beast. Would it be sufficient to have them without depth buffering?

[EgonOlsen]

Hello,

getting back again on this matter, the outcome was because on Hardware Renderer we can blit with a floating coordinate system, whereas in the softwre renderer we can't, but we could use floating type for both and then just use the float point for hardware and cast to int on the software renderer, thus having the legacy code running well keeping compatibilty. I think that was the feasable idea behind this whole conversation.

lemme know if its possible to do or not,

many thanks,

Ok...as always, even simple things are not as simple as they seem at first glance, but this might do the trick:

https://jpct.de/download/beta/jpct.jar

and for jPCT-AE

https://jpct.de/download/beta/jpct_ae.jar

I've simply replaced the int types in the blit methods by floats. It worked fine on my tests albeit I didn't test the actual sub-pixel stuff.