How to use directBitmap()?

I found a weird thing, if my craft up or right through the screen it img becames crash. (left and down are normal)
my code is wrong ???

Have you seen this problem on hardware?

Both hardware and sim are same.
Thats my code: (1.6 KB)

Like @adekto mentioned before, that might be because your bitmap width is not even. Add one empty pixel column on the right to make it even, and try again.

1 Like

I think it cant hand the odd number in the draw routine it als aways is going to start from the higher bits with since it’s not starting at 0*0 on the Sprite but jumps to wat it think is the next town

Same for the right side but then it doesn’t know wen to stop
And that’s how your getting the shifted look

Try make the width even and tell us if that fixes it

Should we fix this in the draw routines? It might course slightly slower draws

Moreover do we fix the API cuz that game.udate(true) is not the most elegant way to turn of screen buffer refresh
Actually allot of inconsistency we can’t really change modes on the fly wich some games might want

It does look to me like the draw routine isn’t clipping the image properly. If you’re using mode13 then it might be my fault, if not, then someone else did it :stuck_out_tongue: But yes, it should be something that is fixed in the draw routine and we shouldn’t leave it to the end coder to fix.

I would not like to slow down the routínes. Many optimizations rely on some kind of constraints. Maybe a separate functions for optimized and normal blitting? Or in this case, it would be good if the tool (Img2pok) would only allow even widths and give an error otherwise.

If it weren’t for the online compiler not supporting C++11 I might have been able to suggest a solution that refuses to compile if the image’s dimensions aren’t even (by using a mixture of templates and static_assert).

It might be possible to provide a function that can handle odd-sized images and then let people pick which function they want to use.
If the odd version is never used then the compiler won’t compile the function.

It would also probably be possible to take advantage of the preprocessor to only enable one version at any given time by using the right define
a bit like how the different screen modes are currently dictated by a define.

1 Like

likes this?

or this?

I thinks that will lost much more memory.

i think most of the draw routine is fine its just its starting point for the top cliping and the return on the side thats the problem that could be fixed with some sort of counter

also speaking of the pre processor defines are a bit of an issue aswell. theres no way to combine the modes like i want a high res splash screen but the rest of the game is in low res fast mode. the user has to do a bit of a hack to get that working

i i think going for a more composite mode one system for basicly all where user draw the buffer themselves as a direct bitmap might be the answer for full custimization and tweaking

nono uhm the problem is coused only by the width and it has to be even not a multiple
just make the image that now is 15x14 to 16x14 should in theory work

Possibly, but @Hanski’s point about optimisation still stands.
Doing that might make the function significantly slower, which is why I think providing alternatives would be a good idea.

When designing an API for an embedded system it’s important to provide the ability to choose between functionality and optimisation

That could be introduced but obviously it would increase the size of the compiled code.

I’m not sure what you mean.

How would that be different to letting the library handle the display buffer?

sorry this is getting of-topic so can i redirect this part of the discussion to here

1 Like



Nice! Cannot wait to see the actual game :wink:

1 Like

Thanks Hanski and everyone else here!!!
Im a beginner and learing C++ by C++ prime now.
If not you helps I cant going on.:+1:


If you ever have any questions about the C++ language,
we have a C++ section where you can ask questions

1 Like

Thanks Pharap!!!:+1:


Let’s make one thing clear here:

Odd numbers (except 1) are evil.

Even numbers are good.

And numbers divisible by 8 are

Edit: this is a joke ofcourse.

But: odd width bitmaps would be slower to draw / require other optimized function.

So: even bitmap widths please