Is there a way I could redraw a bitmap onto itself, just shifted x pixels in one direction?

I'm working on a system for rendering a hexagonal tile map and I want to render each row of tiles as it's own image. when I move to far to the left I wand all the bitmaps to shift their image 1 tile distance to the right and redraw the now missing tile to the left. I could just allocate a new bitmap and switch them out but is there any way I could avoid that and just copy a bitmaps image to itself but offset?

It unfortunately is for performance reasons. I tried just drawing the map every frame but the performance was horrible. I already have a buffer bitmap for resizing the display and another buffer bitmap for the map so I can scale it to zoom in and out. I may be doing things completely wrong in that department which could be my issue but with the added strain drawing the map each frame became too much and the program slowed to a crawl.

I'm drawing tiles to a map bitmap that's being scaled and drawn to a buffer bitmap that's being scaled and drawn to the display. The map isn't just a simple one image per tile either, each tile is a range of 1-25 separate images drawn at twice 1080p so I can zoom out to 0.5. And there's around 100-250 individual tiles on screen at a time. It's a quite a lot.

If you have any idea on how I could improve my scaling I'd love to hear them. I had a version of the program written in c working fine before I added the buffers for resizing the display and scaling the map. My current version is in c++. If you want to look over the code I'm using to do it I could send you a file but I don't want to take up too much of your time. For now I think I'll just attempt the copy over to a new bitmap and swap them method. Even if it's not necessary in the long run I don't think it'll hurt anything.

Just a thought... cannot really help in better way as I am completely new to A5, is it possible that one of your destination bitmaps (scaling buffer, the one you draw your scaled graphics to) is a memory bitmap?
I am not sure if this could slow things down a lot but, before your main loop, possibly you can make sure all your bitmaps are video ones (I think the correct command for this would be al_get_bitmap_flags) and eventually if they are memory based convert them to video ones using al_set_new_bitmap_flags() and al_convert_bitmap()?

Not sure if this can help in any way.

Drawing WIDTH x 2160 x (1-25) * (100-250) is a massive amount of drawing. My first guess would be to use mipmaps but without seeing code and resources I can't guess very well.

Can you make a 7z of your project or is it just too big? Allegr.cc's attachments are limited to 10MB so you might have to upload it somewhere else.

I haven't tried compiling the code though quick-looking at the source I possibly see one thing that appears a bit odd to me (since this is not my source code likely it is my understanding which is off so please be patient).
Namely, in MAP_OBJECT.cpp, lines 157 and 158 would be executed each time the map is drawn - could this be true or is the mapOrientation variable reset somewhere after the initial loading of the bitmaps? If the two commands are executed many times per second this could be a slowdown point as well.

As for the events queue, it is something that I yet have to learn about ...

You can achieve everything you want with transforms alone. I simply draw the same shape at specified offsets over and over and I have no problems. Mind you I don't draw any TILES, only hexagons (filled or outlined). Let me download your code and get back to you.

Ooh, big download...

EDIT
Download complete. Can I take this second to just say VS sucks wad

I'm a snob, but I recommend Code::Blocks nightlies and MinGW-W64. But beneath that you should really learn CMake. Because then you could make VS solutions or CB projects from a simple CMakeLists.txt file and CMake.

First, I haven't even looked at any of your files yet, and all you really needed to share was the files contained in this zip. It's 275KB. Your download was 275MB. That's 1000:1 the size it needed to be. This is why you don't learn real coding at a university. But in reality it is only that size because you included nuget binaries for allegro and its deps. That took up the most size. I don't need those.

I'll get back to you once I get it compiling and such.

PHexMapProject.zip

Edgar

It was pretty easy to compile your code. A few minor mistakes, and one bigger problem - you can't quit.

Other than that, it ran fine?

Here's a diff for you to look at of the minor changes I made.

diff.txt

Note, I am just looking at the code now. Those were the only changes I made to get it to compile without any warnings. Always turn on all warnings.

EDIT1
One thing I will say, is please write a README.txt file that has key controls and screen navigation. I had to guess at everything and quitting using the x button doesn't work on my machine.

EDIT2
You need proper include guards. No more relying on non-portable BS like #pragma. Every header file needs its own set of include guards, with their own unique ID in the define like so :

MySpecialClass.hpp

#ifndef MySpecialClass_HPP
#define MySpecialClass_HPP

/// declarations go here
extern const int ZERO;

class MySpecialClass {
//...
};

#endif // MySpecialClass_HPP

Then you put the definitions in their own source module, as you have been.

EDIT3
Please learn to wrap long lines.

This :

//header
#include "MAP_OBJECT.h"

//construct
MAP_OBJECT::MAP_OBJECT(int seed_input, int size_input, bool biomeToggle_input[], mapTile** tiles_ptr_input, MOUSE_MANAGER* mouseManager_input, KEYBOARD_MANAGER* keyboardManager_input, keyBinding* keybind_ptr)
{

Should be something more like this (most consoles wrap at 80 columns) :

//header
#include "MAP_OBJECT.h"

//construct
MAP_OBJECT::MAP_OBJECT(int seed_input, 
                       int size_input, 
                       bool biomeToggle_input[], 
                       mapTile** tiles_ptr_input,
                       MOUSE_MANAGER* mouseManager_input,
                       KEYBOARD_MANAGER* keyboardManager_input,
                       keyBinding* keybind_ptr)
{

See how much easier that is to read?

EDIT4
Because you have 'z' levels in your hex map, you would have to render it as 3D. Really though, a hexagon is not a difficult shape to replicate. I have a similar hex game, but the hexes are flat on top and bottom instead of the sides. It's in 2D too.

You can achieve everything you want with an extruded 3D hexagon, al_draw_prim and an ALLEGRO_TRANSFORM.

I haven't got to actually running the code yet but what Chris suggests made me lookup a short tutorial for Visual Studio regarding the profiling - new knowledge for me. I don't know if this can help knackname:

EDIT: Actually I wanted to try the profiling tools and got to trying knackname's code. Though please bear in mind that this is my first ever profiling session and I am not very familiar with Allegro5 internals - I am likely wrong about this. I find that in
DISPLAY_MANAGER::draw()
line 137 : al_flip_display();
seems to be reported as taking some 25 ms on my computer (while line before which is full screen al_draw_scaled_bitmap command only takes some 6ms.
Until now I was to believe that flip_display() would be a command executed quite fast but maybe I am mistaken about flip_display()?

EDIT2: knackname, now that I can see your engine in action I could suggest possible improvement though it might be difficult to implement - you will see. The suggestion is that when it comes to drawing stacked towers of tiles you might actually consider starting your drawing loop of a single tower at a value depending on how high the tower "in front" (one closer to the player) is. So if you have one tower obscuring over half of the tower that is behind it - there is no need to draw the tower that is behind completely - you can draw only the visible part. This should reduce overdraw which might further improve the performance.

Optional (if you have the time and energy):
Eventually you might want to try (as a separate project) to see how VBO work - try drawing a hex tile using VBO (while keeping your Z coordinate in VBO at zero - thus making it 2d). I mention this as using VBOs would reduce the number of function calls between your program and the graphic card thus increasing the graphic performance.

Extra optional:
If you do manage to draw a 2d hex tile using VBO then you are not far off from turning that hex VBO tile into a 3d object which, depending on few choices you make in drawing your map, might be another viable solution.
The main choice which might vote in favor of 3d is that if all height levels (of a single hex tile stack that you have in your map) use the same bitmap(texture) to be drawn which seems to be the case at the moment - then using 3d might make it even faster as you could use less than 10 triangles to draw one tile stack which now, by drawing 25 2d tiles, will end up using some 50 triangles total (actually this reduction in triangles would be applicable to 2d VBO as well provided you only use one-two textures to draw the tile stack).

Though keep in mind that it is easy to be carried away when adding new features to your program so being realistic about the available time and energy you have is always a good call. I think that it is better to complete your program even if it is not completely optimized than to try optimizing everything and ending up with a program that is only half of what you wanted it to be.

Vertex buffer object. Videocards are fast but the BUS that connects the CPU to them is super slow (relatively speaking) and becomes a huge bottleneck. So all modern cards use batches of operations instead of commanding individual operations. A "display list" is one way, a VBO is another way. A display list is a batch of commands (drawing, coloring, flipping, whatever), and vertex Buffer objects, IIRC, are just an array color, position and texture data.

But before you get to stuff like that that gives you an extra % speedup, make sure you've fixed the core algorithm of what you're doing--because if that's wrong, you're just wasting time optimizing something that's inherently slow because you chose a really slow way to do something.

In 99% of games with 2-D graphics, if it's slow (even in 1080p) you're probably doing something fundamentally wrong. There are TONS of "bullet hell" games that are likely drawing way more than you are and aren't doing any kind of special tricks to accomplish it. (With 4K, the raw screen area does add up quicker, but it's still correct for general cases.)

I figured out what was happening when Edgar couldn't close the game. When the FPS is too high it takes longer than one frame for the program to draw everything and it skips by the display events in the queue. How do I fix this? I guess I could make a second queue just for the FPS timer separate from the one handling display events?

I tried completely removing the timer from the event queue and It still doesn't work. The program can't keep up with all the drawing 60 times a second and the longer it runs the more and more the draw calls build up. I'll work on optimizing the draw, but now it looks like I need to be dynamically setting my frame-rate to match how long it takes to draw a frame

Update:
I created another method of closing the game, an on screen button in the upper left, and it works perfectly. Something about all the draws is causing a delay with the display's event output. Still experimenting,
i'll update in a bit.

Update 2:
The results are in, I'm just an idiot. I stopped testing for timer event but I didn't actually remove it as an event source so the timer events were still clogging up the queue. I also put in a system to allow it to skip frames if it hasn't finished drawing the last one.