The following code caused a crash.
import "mod_grproc"
import "mod_video"
import "mod_map"
import "mod_draw"
import "mod_rand"
import "mod_say"
private
frnr=0;
begin
set_mode(800,600,32);
set_fps(0,0);
for (x=0;x<250;++x)
put_pixel(rand(0,800),rand(0,600),rgb(rand(200,250),rand(200,250),rand(200,250)));
end
loop
frnr++;
say(frnr);
for (x=0;x<30;x++)
particle(400.0,300.0,(float)rand(-10,10),(float)rand(-5,-10),rgb(rand(150,255),rand(150,255),rand(150,255)));
end
frame(5000);
end
end
process particle(float xcor,float ycor,float dx,float dy, int color);
private
lifetime=100;
begin
graph=new_map(10,10,32);
say(graph);
drawing_map(0,graph);
drawing_color(color);
draw_fcircle(3,3,rand(3,5));
loop
lifetime--;
size+=rand(-2,1);
if (lifetime<0)
size-=2;
//alpha-=3;
if (size<5)
break;
end
end
x=xcor;
y=ycor;
xcor+=dx;
ycor+=dy;
dx*=0.96;
dy+=0.06;
dy*=0.96;
frame;
end
frame;
onexit
if (graph) unload_map(0,graph);graph=0;end
end
I have had crashes like this (http://img253.imageshack.us/img253/4653/blitbug.png) before, but they seem difficult to reproduce. I'm using a fairly recent version of Bennu (29 november 2010)
Last lines in debugger output also suggest a bug in blitting:
[ 158] 000000FF 00000035 ------ D:\Programming\Projects\problem\fireworks.prg:53 -> frame;
[ 160] 00000084 00000064 PUSH 100
00000064
[ 162] 00000002 FRAME
when crash? here are working and don't crash...
maybe you must wait the next release...
Crash happened at frnr==7 for me.
here:
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
and I close it.
For me the crash was at 1209. I've had someone else run it on his machine, it crashes there too. I suspect it's a problem with the scaling code, as this problem also occured when using size_x, size_y in another program. (And it no longer crashes when I comment out the size changes).
I'd like to ask those who read this thread to run it for themselves for a while (10 minutes or so).
It crashed by me too. I've used BGDI 1.0.0 (Nov 29 2010 01:31:19). It carshed at 1119. It cashed after a few seconds. It consistantly
crashes at 1119. I've noticed from the screenshot that you're also using a dutch windows version like me.
I'll test it again...
I tried too, with r147 with this output:
1
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
2
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
3
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
With r181 I get 1119, but crashed too. I'm using Wxp x64.
Just a fast try, not changing code or else, just compile and run.
my version for frmr==4580 and continue...
my version is linux version... I'll let it continue...
my version go frmr == 10604 and continue...
I think that I fix this bug... not blitter problem, pixel (drawing functions) problem...
But I think that I fix it time ago... maybe I made a bad .rar package.
Yeah, maybe it's in the drawing routines. I've played around with some of the primitive drawing fuctions, and they seem to work differently from what I expected from the documentation. delete_draw can sometimes crash in certain situations.
I'm here again... I return from my father house.
I remove say(graph) for more speed in the test.
The test was continue running, I kill it... the last frmr say:
275700
275701
275702
275703
275704
275705
275706
275707
275708
Terminado (killed)
this don't crash in linux.
Strange. Maybe an OS specific issue? Or hardware related?
It's crash on windows...
I isolate the error... this crash for me... please, anybody can confirm please?
import "mod_grproc"
import "mod_video"
import "mod_map"
import "mod_say"
begin
set_mode(800,600,32);
set_fps(0,0);
particle(400,300);
particle(400,300);
particle(400,300);
particle(400,300);
end
process particle(int x,int y);
begin
graph=new_map(10,10,32);
size=1;
say( graph+"|"+size+"|"+x+"|"+y+"|");
frame;
onexit
if (graph) unload_map(0,graph);graph=0;end
end
Yes, it crash
r189 wxp64.
Show this "say":
1000|1|400|300|
1001|1|400|300|
1002|1|400|300|
1003|1|400|300|
put the particle into a for, 0 to 30 or other value.
Quote from: Fede on January 01, 2011, 09:22:23 PM
Yes, it crash
r189 wxp64.
Show this "say":
1000|1|400|300|
1001|1|400|300|
1002|1|400|300|
1003|1|400|300|
thanks fede... well, I now have a test case... I'll fix it later...
for temporal solution, keep width or heigth / size, never give 0.
then if you graph is 10, don't use size lower that 10.
try with this libblit...
thanks for the report... karma++
sorry, this is the right file...
With old libblit (r181) I changed code to:
import "mod_grproc"
import "mod_video"
import "mod_map"
import "mod_say"
begin
set_mode(800,600,32);
set_fps(0,0);
loop
particle(400,300);
if (key(_esc)) break; end
frame;
end
end
process particle(int x,int y);
begin
graph=new_map(10,10,32);
size=1;
say( graph+"|"+size+"|"+x+"|"+y+"|");
frame;
onexit
if (graph) unload_map(0,graph);graph=0;end
end
With no crash. With new libblit I have no crash too.
yes, several particles in the same loop.
I need test the previous test sample.
tic tac, tic tac...
and ????
eckolin???
Hello,
I have a similar issue. When I ussing size_x with lower value that 10, sometimes the program crash. In the other hand, i tried to run it in debug mode, and I can't reproduce the crash. If I change anything of code, sometimes is possible that it run correctly. I think that it is a possible bug in this function, but I not rule out that this is a bug in my code...
Regards!
Quote from: Arcontus on February 26, 2011, 04:18:13 PM
Hello,
I have a similar issue. When I ussing size_x with lower value that 10, sometimes the program crash. In the other hand, i tried to run it in debug mode, and I can't reproduce the crash. If I change anything of code, sometimes is possible that it run correctly. I think that it is a possible bug in this function, but I not rule out that this is a bug in my code...
Regards!
which version?
Quote from: SplinterGU on February 27, 2011, 01:44:13 AM
Quote from: Arcontus on February 26, 2011, 04:18:13 PM
Hello,
I have a similar issue. When I ussing size_x with lower value that 10, sometimes the program crash. In the other hand, i tried to run it in debug mode, and I can't reproduce the crash. If I change anything of code, sometimes is possible that it run correctly. I think that it is a possible bug in this function, but I not rule out that this is a bug in my code...
Regards!
which version?
I Tried to update to last version yesterday (bgd-1.0.0RC21(r228)-win32), and I have equal result. I don't understand what is the problem if the mistake is in my code, because all times the program execute the same process, and it work fine if I change the minimum value for size_x over 10.
mmm, I already fix this bug... can you send me a sample with this error?
Quote from: SplinterGU on February 28, 2011, 02:47:26 AM
mmm, I already fix this bug... can you send me a sample with this error?
It's difficult because the program have a lot of lines for analice all code, but the implicated process is very simple:
PROCESS BarraEnergia()
PRIVATE
contador;
BEGIN
file=interfazFPG;
x= 468;
y=Resolucion_y -140;
graph = 26;
z = Z_INTERFAZ+1;
LOOP
if (contador < 1) contador = 100;else contador--;END
size_x = contador;
if (contador > 90)
graph = 26;
else
if (contador > 80)
graph = 27;
else
if (contador > 70)
graph = 28;
else
if (contador > 60)
graph = 29;
else
if (contador > 50)
graph = 30;
else
if (contador > 40)
graph = 31;
else
if (contador > 30)
graph = 32;
else
if (contador > 20)
graph = 33;
else
if (contador > 10)
graph = 34;
else
if (contador > -1)
graph = 35;
END
END
END
END
END
END
END
END
END
END
FRAME;
END
ENDThis process countdown every frame the variable "contador", and it's equal to size_x. For other hand, the anidated "IFs" is for change the collour of the bar every 10 values. The graph that I use for this function have a resolution 373x7 pixels. When I tried to debug this code with debug mode, never crash. It's very strange.
I don't try if the code of this process alone can run fine (obviously with main process).
If antythink don't understand, I can send you the reply in spanish if you prefer :D
Thank you,
Regards!
I need a compilable code.
Quote from: SplinterGU on February 28, 2011, 07:24:24 PM
I need a compilable code.
Ok, I'll send you when it's ready.
Sorry, you were right. I was ussed an obsolete version, and I was an error when I tried to change the current version in my compiler. With the new version, run fine.
Thanks again.
;)