Community
Message Board

Chat room - users
Game Over
( 394431 downloads)
Work In Progress
( 523201 downloads)
Links

Code Exchange
Downloads
Tutorials
Add to Favourites

Submit news

DIV ARENA FORUMS
Not logged in [Login - Register]
Go To Bottom

Printable Version  
 Pages:  1  2    4    6  7
Author: Subject: Nightly build bug reports
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 30-1-2017 at 09:48 AM


Quote: Originally posted by RKSoft  
So, i changed some thing in code and now it works perfect. I release the next beta here next day because i will finish some thing.

The bug occurs when process created but the main game isn't ready to go! The stop_scroll() bug isn't realy a bug. But this feature(1) occurs on Malvado, too!!!
I added a little loop into all process. This will wait until all process created and the setup_level is finish. The var PROGRAM_CONTINUE will set to true and the main loop with all process started his work.

And finally, the process explorer shows all 88 processes every start/kill/win etcl.! :)

This suggests that there is a bug in the task manager, but it could not be.

I analyzed the better your PRG original and there are some errors, especially in the "setup_level" process:

1) the "CLEAR_SCREEN" function call is not necessary, you are not using any put function to draw the background.

2) the call to START_SCROLL is carried out at the wrong time, it should be called before the creation of the scroll-type processes, to prevent the jobs that are wrong "code".

3) Each game reset, new texts are created (WRITE_INT) without having eliminated the previous ones, it should be called the DELETE_TEXT(ALL_TEXT) function.

I think I have identified the possible bug, occurs with the call to STOP_SCROLL for some reason, commenting the call and using LET_ME_ALONE, the game works well without crash or freeze (at least on my machine).

I add here the PRG that had initially deployed, with the necessary modifications, in order to test whether it works well in other machines

.

Attachment: smb.prg (28kB)
This file has been downloaded 2232 times

View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 30-1-2017 at 03:47 PM


I agree with Cictec ^^. In my current beta version, i created the scroll first and then the processes that will be show in.
With CLEAR_SCREEN, thanks for that info. I thought, i needed it for clearing the screen completely (Blitz BASIC, BASIC dialects etc.)
And, tadadaaa, i readed the info about write/write_int and defined vars for every write command to clear that after game is over.

I'm sorry that i thought there is a bug into DIV. But DIV works completely different than other programming languages and i forget that.
I worked with functions (ie: Blitz BASIC, PAWN, PHP etc.) and functions works not like processes.

Function: A sub program that we can call and that will run once
Process: A complete selfrunning program that we need to kill when we do not need anymore.


So, i recommend for every process:

- first, use a loop before the main code of that process should be start
- use a global variable for all first-start-loops (in all processes) that checked when this var is set to true, break this loop
- set the global var to true when all setup and intialisings are finish and the game can start

My little example:



Code:
program process_test local program_ready; begin program_ready = false; initial_my_game(); while (not program_ready); frame; end loop frame; end end procress im_a_process() begin while (not program_ready); frame; end loop frame; end end process intial_my_game() begin /* here me setup/initial code like loading fonts, maps, fpg, sounds etc. */ im_a_process(); im_a_process(); im_a_process(); program_ready = true; end



[Edited on 30-1-2017 by RKSoft]
View user's profile Visit user's homepage View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 30-1-2017 at 05:29 PM


Can you "remove" this bug by calling frame() before any processes are spawned?
View user's profile View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 30-1-2017 at 06:12 PM


Quote: Originally posted by RKSoft  
I agree with Cictec ^^. In my current beta version, i created the scroll first and then the processes that will be show in.
With CLEAR_SCREEN, thanks for that info. I thought, i needed it for clearing the screen completely (Blitz BASIC, BASIC dialects etc.)
And, tadadaaa, i readed the info about write/write_int and defined vars for every write command to clear that after game is over.

I'm sorry that i thought there is a bug into DIV. But DIV works completely different than other programming languages and i forget that.

No problem, do not worry, DIV works differently to normal programming languages, it is normal to be confused. :)

The bug actually exists, as the example of Dr. Malvado and seems to be initiated by something that is executed by the call to STOP_SCROLL.

Quote: Originally posted by RKSoft  

Function: A sub program that we can call and that will run once
Process: A complete selfrunning program that we need to kill when we do not need anymore.


So, i recommend for every process:

- first, use a loop before the main code of that process should be start
- use a global variable for all first-start-loops (in all processes) that checked when this var is set to true, break this loop
- set the global var to true when all setup and intialisings are finish and the game can start

My little example:



Code:
program process_test local program_ready; begin program_ready = false; initial_my_game(); while (not program_ready); frame; end loop frame; end end procress im_a_process() begin while (not program_ready); frame; end loop frame; end end process intial_my_game() begin /* here me setup/initial code like loading fonts, maps, fpg, sounds etc. */ im_a_process(); im_a_process(); im_a_process(); program_ready = true; end



[Edited on 30-1-2017 by RKSoft]

Well, maybe this works for now, but you do not really need this in order to obtain proper operation.


Quote: Originally posted by MikeDX  
Can you "remove" this bug by calling frame() before any processes are spawned?

Tried, continues to fail if it is called STOP_SCROLL.

I tried the original example of RKSoft and my modified in the original version of DIV2 via dosbox and other, both work properly.

Have you changed something in the process system, scroll, or maybe correct some apparent bug that causes this error now?

[Edited on 30-1-2017 by CicTec]
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 30-1-2017 at 06:47 PM


Ahh, also the bug is in the port of DIV DX and not in original DIV1/2? However, my example fix this problem and i hope it could help others with their projects. :)
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 30-1-2017 at 06:57 PM


Quote: Originally posted by RKSoft  
Ahh, also the bug is in the port of DIV DX and not in original DIV1/2? However, my example fix this problem and i hope it could help others with their projects. :)

Yes the problem appears only in DivDX for what I've seen so far.
View user's profile View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 30-1-2017 at 07:48 PM


If this is a bug in DIV-DX this will be a real pain to track down, but hopefully with good examples of how to reproduce we can fix it!
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 30-1-2017 at 09:20 PM


Mike, you can test it with Malvado. Start game, jump on a bear ... when the stars appears press ESC ;)

I think when the stop_scroll is called and a process -which is defined for that scroll- do a frame it freezes because the scroll isn't.

[Edited on 30-1-2017 by RKSoft]
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 30-1-2017 at 09:52 PM


Quote: Originally posted by RKSoft  
Mike, you can test it with Malvado. Start game, jump on a bear ... when the stars appears press ESC ;)

I think when the stop_scroll is called and a process -which is defined for that scroll- do a frame it freezes because the scroll isn't.

[Edited on 30-1-2017 by RKSoft]

Yes but in the case of your game happen:
1) The game returns to the environment of DIV development, when the player is killed.
2) The game will freeze in infinite loop when the player is killed.

The second case clearly indicates that some part of the code containing loops, can not end (perhaps the condition of control variables do not update properly), the problem is that the engine has plenty loops internally (process manager, frame manager, etc...) to find the exact point is very hard, you would need an example as simple as possible to reproduce the same problem, in order to analyze a few pieces of code one by one until you find the freezing point.
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 31-1-2017 at 01:57 PM


I thought Mike used the DIV2 engine and let it run on other os with different dll's (like emulation)? Did he rework the DIV2 engine (for dos)?
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 31-1-2017 at 04:42 PM


Is the original DIV2 engine, translated to modern compilers, added SDL to operate in new platforms and OS, small improvements and many bugs fixed, maybe some translation or bugfox caused this new bug, or simply some original code does not work as expected with new compilers and should be changed, can be anything.
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 1-2-2017 at 04:23 PM


Ok, how can i help you to find the bug? Please let me know!

[Edited on 1-2-2017 by RKSoft]
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 1-2-2017 at 05:14 PM


One way would be to create a smallest possible example which reproduces the same bug, to reduce the search areas on which check.

Yesterday I tried to make some changes to the core (interpreter), restoring the original code from the changes made by Mike, but the result is that now your example returns to the environment DIV at each performed action (press ESC, killed by any enemy), it is not easy to find and the structure of the code does not help the search.
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 1-2-2017 at 10:41 PM


Try this little test out. By pressing ESC it is interesting what happen. ^^

@maincode
- Comment out the frame after loop in main code it occurs an error.
- With frame, the programm quits after pressing ESC!

@moving
- Using scroll.camera = id is different than manuell scrolling with scroll[0].x register. Try it out.

@program
It runs but not i thought. Why? Maybe this can help finding the bad hidden bug in the engine.

Attachment: Test.zip (25kB)
This file has been downloaded 2178 times

View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 2-2-2017 at 11:16 AM


Quote: Originally posted by RKSoft  
Try this little test out. By pressing ESC it is interesting what happen. ^^

Tried...

Quote: Originally posted by RKSoft  

@maincode
- Comment out the frame after loop in main code it occurs an error.
- With frame, the programm quits after pressing ESC!

This happens because seems that does not run the while, and runs much faster set_up() until you reach the limit of 64.

Quote: Originally posted by RKSoft  

@moving
- Using scroll.camera = id is different than manuell scrolling with scroll[0].x register. Try it out.

This is normal for the internal implementation of the core system, the IDs are different depending on the amount of code and declared variables.

Quote: Originally posted by RKSoft  

@program
It runs but not i thought. Why? Maybe this can help finding the bad hidden bug in the engine.

Perhaps by accident.

I believe that this is a core issue running, or it could also be that the compiler generates an incorrect code or "different" from what you should read the core.

Try this modification:
Code:
program test; global file_fpg; fpgs = 0; main_count = 0; begin //set_mode(m320x200); set_fps(30, 2); write_int(0, 160, 10, 4, &main_count); write_int(0, 160, 20, 4, &fpgs); loop main_count++; fpgs++; set_up(); repeat frame; until(key(_esc)); //while (not key(_esc)); frame; end //frame; /* <-- comment this out will be an error after pressing ESC */ stop_scroll(0); end end

Try different combinations, for example:
- Use WHILE, FRAME, comments STOP_SCROLL.
- Use REPEAT, FRAME, comments WHILE and STOP_SCROLL.
- Use REPEAT, STOP_SCROLL comments WHILE and FRAME.
etc...

When you can use the debugger to examine the value of variables.

You'll see that with every run and combination of code, there will be different results.

[Edited on 2-2-2017 by CicTec]
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 2-2-2017 at 04:53 PM


Hm, also you can't find the engine bug in this code? It is strange that my game (previous version) could freeze DIV but this test program not.
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 2-2-2017 at 05:11 PM


Quote: Originally posted by RKSoft  
Hm, also you can't find the engine bug in this code? It is strange that my game (previous version) could freeze DIV but this test program not.

This also freezes DIV test, simply says the call to STOP_SCROLL and uses the WHILE and REPEAT, pressing esc sometimes the program will be blocked (frozen).

From this last test, the most likely cause is a bug in the interpreter, and should control it all, but it could also be in the compiler, or more of a bug, it's not easy to find.
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 6-2-2017 at 04:30 PM


So, another bug found but it is in compiled version. I used the latest nightly build (see above). Take a look at my task manager.

The Jumpman tutorial game used 1.4GB RAM? Not really or? I think this is a bug in the compiled (.exe) version because the in-DIV-version used ca. 12 MB.

task.jpg - 122kB
View user's profile Visit user's homepage View All Posts By User
MikeDX
DIV Nerd
*********


Avatar


Posts: 8388607
Registered: 25-2-2016
Member Is Offline


[*] posted on 6-2-2017 at 05:02 PM


That seems insane! I wonder if we have a memory leak

Some things are unpacked and loaded into ram but that's crazy
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 6-2-2017 at 10:05 PM


Sure, its crazy because in DIV the game use only ~12 MB RAM ;). I hope it can be fixed soon as possible because we want release games as exe (for Windows as example). ^^
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 7-2-2017 at 10:00 AM


Quote: Originally posted by RKSoft  
So, another bug found but it is in compiled version. I used the latest nightly build (see above). Take a look at my task manager.

The Jumpman tutorial game used 1.4GB RAM? Not really or? I think this is a bug in the compiled (.exe) version because the in-DIV-version used ca. 12 MB.


Hi RKSoft,

Please try to recreate EXE with this modification:
Code:
begin set_mode(m320x200); set_fps(30, 2); file_enemies = load_fpg("enemies.fpg"); file_effects = load_fpg("effects.fpg"); file_extras = load_fpg("extras.fpg"); file_font8x8w = load_fnt("smb8x8w.fnt"); file_font8x16w = load_fnt("smb8x16w.fnt"); file_player = load_fpg("player.fpg"); file_screen = load_fpg("screens.fpg"); animcounter(); loop /* Code: Title */ game = false; player_dead = false; player_win = false; program_continue = false; setup_level(0); while (not program_continue); frame; end x = 160; y = 100; file = file_screen; graph = 2; fade_on(); loop if (key(_esc)) exit("Jumpman quits here!", 1); end if (key(_space)) player_dead = true; program_continue = false; break; end frame; end while (not program_continue); frame; end fade_off(); frame(3000); //stop_scroll(0); /* Code: Initial the game */ player_coins = 0; player_level = 1; player_lives = 4; player_score = 0; player_world = 1; font_score = write_int(file_font8x8w, 76, 15, 2, &player_score); font_lives = write_int(file_font8x8w, 96, 7, 1, &player_lives); font_coins = write_int(file_font8x8w, 144, 15, 2, &player_coins); font_world = write_int(file_font8x8w, 196, 15, 0, &player_world); font_level = write_int(file_font8x8w, 212, 15, 0, &player_level); font_time = write_int(file_font8x8w, 276, 15, 1, &player_time); /* Code: Game */ loop //file_screen = load_fpg("screens.fpg"); player_dead = false; player_win = false; program_continue = false; setup_level(player_level); while (not program_continue); frame; end file = file_extras; graph = 1; x = 0; y = 0; time_count = 0; fade_on(); while (game) time_count ++; if (time_count > 25) time_count = 0; player_time --; if (player_time < 1) player_dead = true; program_continue = false; break; end; end if (key(_esc)) player_dead = true; program_continue = false; break; end frame; end while (not program_continue); frame; end if (player_dead) player_lives --; if (player_lives < 0) font_gamestatus = write(file_font8x16w, 160, 100, 1, "game over"); frame(10000); fade_off(); frame(2000); delete_text(font_gamestatus); break; end end fade_off(); frame(2000); //stop_scroll(0); end /* Code: Uninitial the game */ delete_text(font_coins); delete_text(font_level); delete_text(font_lives); delete_text(font_score); delete_text(font_time); delete_text(font_world); graph = 0; frame; end end


Try, please, even to generate an EXE uncommenting the calls to STOP_SCROLL and compare if the memory levels are different.
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 7-2-2017 at 01:24 PM


Same problem!!!

And, the file_screen = load_fpg(...) must be inside the loop because in-game it deletes something in the hardmap and at a restart it will be needed. ;)
And, why not stop_scroll(0)? Did you think thats can be the error?

@this ram bug
why is the ram when the program is running under the DIV editor at ~12MB and compiled ~1.4GB?`I think the bug is in the compiler or in a DLL.
View user's profile Visit user's homepage View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 7-2-2017 at 02:18 PM


Quote: Originally posted by RKSoft  
Same problem!!!

And, the file_screen = load_fpg(...) must be inside the loop because in-game it deletes something in the hardmap and at a restart it will be needed. ;)
And, why not stop_scroll(0)? Did you think thats can be the error?

Ok, It was to carry out some tests.

STOP_SCROLL is not necessary if you reuse a call to START_SCROLL in the same window, as if invoked, implicitly makes an automatic STOP_SCROLL and then re-creates the window with the new parameters.

Quote: Originally posted by RKSoft  

@this ram bug
why is the ram when the program is running under the DIV editor at ~12MB and compiled ~1.4GB?`I think the bug is in the compiler or in a DLL.

Probably the bug is in the RELEASE version of the core, or in the packing system, the IDE does not use the packing system and how core uses the DEBUG version (for the debugger, etc ...), so maybe see this difference.

@offtopic:
As suggestions for your tutorials, when you create a single instance of a type of process (eg Player) do not use COLLISION(TYPE name), because this has to find the process in all of the active processes list, get the ID with player_id = player (...), then uses COLLISION(player_id), this makes your programs more efficient.

[Edited on 7-2-2017 by CicTec]
View user's profile View All Posts By User
CicTec
DIV Pro
******




Posts: 471
Registered: 6-8-2016
Member Is Offline


[*] posted on 8-2-2017 at 01:17 PM


Quote: Originally posted by RKSoft  

Found follow bugs:
....
- PNG, GIF, JPEG doesn't work, why?

Hello RKSoft,

You may specify please in more detail the things you mean by "not working", where these formats do not work?
View user's profile View All Posts By User
RKSoft
Game Making Machine!
******


Avatar


Posts: 232
Registered: 1-3-2016
Location: Germany
Member Is Offline


[*] posted on 9-2-2017 at 07:27 PM


All, PNG, GIF, JPEG doesn't work in loading maps or as background for DIV ;). It tells me filetype not recognised. It only work BMP, PCX or map.

Tested with the latest nightly build, too: div-beta-nightly-2017-02-08-fb9d1ac228-win32

[Edited on 9-2-2017 by RKSoft]
View user's profile Visit user's homepage View All Posts By User
 Pages:  1  2    4    6  7

  Go To Top

Powered by XMB
XMB Forum Software © 2001-2012 The XMB Group
[Queries: 18]