Hi. I am very new to Allegro and trying to make an RPG game.

In game_run(), I intend to show a couple of dialogues before continuing the game in the if(dialogue) bit. Though for some reason after the dialogue ends, the game will crash and the console says:

Process returned -1073741819 (0xC0000005)

I'm not sure what I did wrong, can somebody point out my mistakes?

Please take a look at my really messy code and bear with me:
[EDIT] some clean up, which I'm not even sure will matter

Thank you so much!

Can you not step through it with a debugger and see the stack trace... That would help you loads

I believe you need to move your:

timer  = al_create_timer(1.0/FPS);
al_register_event_source(event_queue, al_get_timer_event_source(timer)) ;
al_start_timer(timer);

outside of the game loop (possibly to your init function) - right now I believe you are creating a new timer each iterration of the loop.

EDIT: Also, your process_event(); function does not contain the part that would be processing the timer events. Have a look at https://github.com/liballeg/allegro5/blob/master/examples/ex_timer.c lines from 141-161 for an example of an event processing loop.
Eventually if you get stuck please let us know and we'll do our best to help you fix this.

Hi, thank you for all the replies.

@pmprog: sorry, what is a stack trace?

@MikiZX: thank you for the reference and suggestions. I've moved the timer to init now. From the sample code that I've seen, they only used the timer to animate some sprites. I'm still confused about the timer concept; is it to make sure that the game runs on a stable FPS?

---

From the source codes that I've seen in Allegro game development, it's either too complicated that I can't understand the structure or too basic.

As my function if(dialogue) causes the game to crash due to infinite loop, I want to ask: is there a way to show a dialogue text box like in most RPG style games?

Again, thanks for the feedback and guidance.

The main purpose of timers is to ensure that your game runs at the same speed on different computers.

@childski, A stack trace is a list of functions that the current execution leading up to your crash.

Personally, i think debugging is just as important as coding, so I'd honestly recommend learning how to use a debugger. Depending on what language/toolchain you're using, they're all a little different, but the concepts are generally consistent

@LennyLen thanks! that cleared me up a bit. I'll just have to somehow implement it...

@pmprog Ok, so I've found that my problem is in the if(dialogue) part, which now I've cleaned up a bit, but still have problems with.

In my game_run() function, I understand that it loops until the game stops. The problem arises when I set dialogue=false (i.e the dialogueindex reaches 12), and then the game crashes. Until today, I'm still not sure why and what could be done to actually fix it

I had a second look at your source and possibly you need to test this line:
case DIALOGUE:
if(dialogueindex<sizeof(dialogue1)-1)

My programming skill is not that good (and I'm too lazy to test) but maybe sizeof(char* x) will not return the number of elements in the array?
Maybe test this part with something like:
case DIALOGUE:
if(dialogueindex<5)

As for displaying the dialogue there is no special way - you choose how to do it (you can just print text to the screen).

Some people here that understand C++ better can also confirm if your code is C or C++ since you are using #include <string> .. I am not sure if this changes anything.

As for timers....

Hm.. I'll try to explain part of the situation.

I have had a look at your game code and your game actually does not have a fixed speed at which it is executed because at the moment you only make things happen when there is some input to your game (like a keypresses for example) - the main loop of your game is executed as fast as your computer/operating system can run it.

Even if this is OK for a game to run only when there is input - this is not what majority of game devs do.
You can make a game without using a timer - they are only there to help with things (like animations and movement being executed at a fixed speed on different computers). In your case you can remove the timer completely and depend on keypresses to advance the dialog.

You can create multiple timers that can run in parallel - one timer to be executed 60 times a second, another that executes only once every 5 minutes, etc... Each time the timer ticks (is executed) there will be a new ALLEGRO_EVENT_TIMER in the event queue and your main loop can be designed to do something when it this event appears.
Timers are there to provide timing facility - a tool for you to use if you see the need.

On the other hand, you will have to add processing for different events in your loop (like window managment for example).
This is needed as things will happen outside the game (at operating system level) but that will cause Allegro5 to add a new event to the event queue. Your game needs to process these events to continue working without hickups (example here is when someone tries to close the game by clicking on the X button (or red circle) in the corner of the window - your game needs to process even this and close itself; another example is when someone resizes the window that your game has opened) - you process these events in your main loop(s) as you see fit - there is no special procedure to follow.

If your game was just running in a loop without a timer (as it is doing so now) then you will need to calculate time elapsed between two frames (two iterrations of the loop) of the game and move and animate the game assets using this delta time in order for the movement and animation to be done at the same speed/rate on different computers. Using a fixed timer simplyfies things in this regard as you can always use the same values to advance animation or change position.
Using a fixed timer that ticks 30 or 60 times a second will not change your game code much (actually very little) but might prove to be easier to manage later when you will want to add ide animation to your main game character or similar.

Do not take all this I have written as 100% true (as I am learning Allegro as well) but it is there to give you some general idea of why timers could be usefull for you (or not needed at all).

Please let me know if there is any particuar reason you wish to create your game without a fixed timer - or if you see no problem to re-arranging your main loop so it fits the 30 or 60 ticks per second type of executing as I can eventually (if you get stuck) change your code so it runs at fixed rate using a timer.

I think i know what your problem is, but seriously, invest some time into a debugger.

Failing that... I used to be taught what was called a dryrun. Where you run line by line through your head, keeping track of the variables on a bit of paper

I really just want to say the problem i see, but part of me hopes you'll try the debugging

Edit: A hint is that you are actually overflowing your dialogue array, which is why it's crashing
Edit 2: Hmmm, maybe that's not even totally correct, but you can never leave the dialogue system

@MikiZX That was very helpful and eye-opening! Thanks a lot for the explanation. And yes, I've now implemented the correct way to calculate the elements of the char* array, now it's fixed! :')

It's not that I do not want to use a timer, it's just that I probably have no idea how to correctly use one. Though I am currently trying to incorporate it into my game loop. I do wish my game can be run consistently on every computer, just... figuring it out.

Again, thanks for the great help

---
@pmprog I am running this code in code::blocks using the GDB debugger and there were no errors regarding the array part. Although now I've solved it. The mistake is in calculating the elements of the char* array. I used sizeof(), which does not return the number of elements.

I'm not sure if you're referring to another type of debugger/debugging? I'm confused.
but thanks for the hints and suggestions!

@childski: Then yes, you were overrunning the array. Whilst that in itself doesn't error, it leads you to access incorrect/invalid memory, which is what causes the error.

Also line 336 always sets your state to DIALOGUE, you'll never be able move on from the dialogue section

There are multiple ways to use a debugger. CB is just handling the interface for you. Setting breakpoints, stepping, so on....

There's a little guide I wrote to gdb here : (you'll notice there is a terminal in CB for talking to gdb)
https://github.com/liballeg/allegro_wiki/wiki/Debugging-and-logging-with-A5#debugging-with-gdb