How to use directBitmap()?


#61

Ok so the with the true is an overload of the low resolution mode I know it’s a bit messy but this was to disable the screen refresh. drawbitmap draws to buffer direct bitmap is direct ly to lcd
The 16palet buffer is 11088 half the resolution since it’s in RAM
There is a 4 color mode with a buffer that’s 220
176

To get rid of old Sprites in direct mode you have to manage that manually this gets complicated fast so would recommend avoiding it or cheating with a single color background and drawing a rectangle on top the old location


#62

Thanks
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 ???



#63

Have you seen this problem on hardware?


#64

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


#65

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.


#66

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


#67

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


#68

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.


#69

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.


#70

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
(e.g. #define POKITTO_ALLOW_ODD_IMAGES or #define POKITTO_EVEN_IMAGE_OPTIMISATION),
a bit like how the different screen modes are currently dictated by a define.


#71

likes this?

or this?

I thinks that will lost much more memory.


#72

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


#73

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


#74

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?


#75

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


#76

wonderful!!!


#77

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


#78

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:


#79

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


#80

Thanks Pharap!!!:+1: