| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
 Verfasst am: 27.11.2011, 00:48 Titel: GFX Bug oder Programmfehler? |
 |
|
Ob es wirklich ein Bug ist weiß ich nicht!
Aber nachdem ich die Situation hier nochmal vereinfacht
ausprobiert habe und sich der Fehler doch reproduzieren läßt...
Ich erzeuge einen Screen und ein kleines Objekt.
Eine der Methoden des Objektes soll, neben anderen Sachen
ein Image erzeugen bzw. vergrößern.
Der Screen selbst ist noch nicht benutzt(beschrieben oder bemalt) worden
Jedenfalls erzeugt die Methode durch mehrmaligen Aufruf hintereinander(was so sein soll,Imagevergrößerung
ist ja nur eine Aufgabe) Fehler im vergrößerten Image!!!
Ein einfaches "PRINT" innerhalb der Methode scheint das Problem zu lösen.
Ist das ein Bug oder liegt der Fehler in den paar Zeilen hier?
| Code: | screen 19,32
type test
imgsize as integer
img as integer ptr
declare destructor
declare sub MakeItBigger
end type
destructor test
if img then imagedestroy img
end destructor
sub test.MakeItBigger
'print'<------------------------------!!!!????
imgsize +=50
if img then imagedestroy img
img=imagecreate(imgsize,imgsize,&HFFFFFF)'Weiß gefüllt
line img,(0,0)-(imgsize-1,imgsize-1),&HFF0000,bf'Zur Kontrolle Rot auffüllen
end sub
dim as test x
print
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
put (0,0),x.img,pset
sleep |
Mutton |
|
| Nach oben |
|
 |
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4702
Wohnort: ~/
|
| Verfasst am: 27.11.2011, 00:57 Titel: |
|
|
Wie wirkt sich der Fehler denn aus? Ich sehe hier unter Linux nichts ungewöhnliches, was einen gfx-Fehler unter Windows nahe legt.
Möglicherweise sorgt das PRINT für eine kleine Atempause für die Routinen; wie sieht es aus, wenn du stattdessen zwischen den Vergrößerungen ein SLEEP 1 einfügst? Meine Vermutung ist, dass hier die eine Grafikbearbeitung intern noch nicht "fertig" ist, wenn die nächste startet.
edit: 3000 
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
| Verfasst am: 27.11.2011, 01:02 Titel: |
|
|
Die rote Füllfarbe durch den LINE Befehl ist nur im oberen Bereich, anstatt vollständig
Vielleicht betrifft es ja nicht TUX
edit:
ein SLEEP 3000 ???  |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 27.11.2011, 01:15 Titel: |
|
|
Das ImageDestroy zu entfernen "behebt" den Fehler auch, was wie in fast allen Fällen von "seltsamen" Gfx-Bugs ganz verdächtig nach irgendeinem Speicherzugriffsfehler riecht, nicht nach einem Fehler in der Print-Routine.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
| Verfasst am: 27.11.2011, 01:20 Titel: |
|
|
| Dann muß dieses Problem aber schon länger mit dabei sein... hab das Problem beim Arbeiten an meinem Achsenmodell bemerkt und auch mal mit dem 0.21 compiliert,gleiches Ergebnis |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 27.11.2011, 01:46 Titel: |
|
|
unter linux funzt es.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Eternal_pain
Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA
|
| Verfasst am: 27.11.2011, 10:57 Titel: |
|
|
In deinem Beispiel find ich das ergebnis unter Windows zwar verwunderlich, aber dennoch dürfte es eher daran liegen das du hier immer wieder ein Imagecreate aufrufst ohne das dieser wieder freigegeben wird...
Das mit dem destructor is zwar nett gedacht, nutzt in diesem Beispiel aber nichts... du rufst deine funktion 5 mal auf 5x imagecreate und am programende kommt erst der destructor mit 1x imagedestroy zustande (die anderen 4 werden dabei nicht mehr freigegeben)
Wird imagedestroy nach dem 'putten' bzw nach dem aufruf der sub direkt ausgeführt bleibt auch der fehler aus
_________________
 |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 27.11.2011, 12:45 Titel: |
|
|
eigetnlich passt das schon, was er da macht.
das destroy hat er auch mit makeitbigger drin, und zwar in der zeile for dem imagecrate, und nicht nur im destructor.
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
Eternal_pain
Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA
|
| Verfasst am: 27.11.2011, 14:59 Titel: |
|
|
Ok, das hatte ich übersehen, hatte allerdings bei meinem Versuch so anschliessend funktioniert...
Sieht dann aber deutlich nach einem fehler in line aus...
die Variablenwerte stimmen ja und sollten auch korrekt arbeiten, interessant find ich die kleine änderung des Beispiels, das im letzten kästchen das ergebnis genauso aussieht obwohl ich eine geringere Breite angegeben habe
| Code: |
Sub msg(message as string)
dim ff as integer
ff = FreeFIle
open cons for output as #ff
print #ff, message
close #ff
end sub
screen 19,32
type test
imgsize as integer
img as integer ptr
declare destructor
declare sub MakeItBigger
end type
destructor test
if img then imagedestroy img
end destructor
sub test.MakeItBigger
Dim lsize as integer
imgsize += 50
msg "imgsize: "+str(imgsize)
if img then
imagedestroy(img)
img = 0
msg "Imagedestroy"
end if
img = imagecreate(imgsize,imgsize,&HFFFFFF) 'Weiß gefüllt
lsize = imgsize-1
msg "lsize: "+str(lsize)
line img,(0,0)-(lsize-10,lsize),&HFF0000,bf'Zur Kontrolle Rot auffüllen
end sub
dim as test x
print
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
put (0,0),x.img,pset
sleep
|
_________________
|
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
| Verfasst am: 27.11.2011, 15:26 Titel: |
|
|
EDIT:
Ein kleines Workaround scheint das Problem zu beheben:
| Code: |
sub ImageReSize(byval img as integer ptr, sizex as integer,sizey as integer)
dim as integer ptr imgtmp
imgtmp=imagecreate(sizex,sizey)
if img then imagedestroy img
img=imgtmp
end sub |
....scheint leider auch nur 
byval.... Hust... byref natürlich...
Zuletzt bearbeitet von Muttonhead am 27.11.2011, 21:20, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 27.11.2011, 20:50 Titel: |
|
|
kurioser Fehler!
Ich vermute den Fehler auch in LINE.
Auch ein Workaround, oder?
| Code: | Screen 19,32
Type test
imgsize As Integer
img As any Ptr
Declare Sub MakeItBigger
Declare Destructor
End Type
Destructor test
If img Then ImageDestroy img
End Destructor
Sub test.MakeItBigger
Dim tmp As Any Ptr
imgsize +=50
tmp=ImageCreate(imgsize,imgsize,&HFFFFFF)'Weiß gefüllt
If img Then ImageDestroy img
img=tmp
Line img,(0,0)-(imgsize-1,imgsize-1),&HFF0000,bf'Zur Kontrolle Rot auffüllen
End Sub
Dim As test x
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
x.MakeItBigger
Put(200,0),x.img,PSet
Sleep |
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Muttonhead
Anmeldungsdatum: 26.08.2008
Beiträge: 565
Wohnort: Jüterbog
|
| Verfasst am: 27.11.2011, 21:04 Titel: |
|
|
@Volta:
Deine Variante scheint zu funktionieren, direkt im Code...
Hmmm... ein Lichtblick?.... mal testen 
edit:
Japp das scheint ordnungsgemäß zu funktionieren... meine Sub nun auch
Ich betrachte das mal also gelöst und bedanke mich mal bei allen |
|
| Nach oben |
|
|
Eternal_pain
Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA
|
| Verfasst am: 28.11.2011, 18:07 Titel: |
|
|
hm.. hätte man eigentlich gleich drauf kommen können :S
ähnliche fehler entstehen auch wenn man ein bereich mit (c)allocate immer wieder neu (re)initiiert, auch da hilft dieser einfache weg über eine temp variable...
_________________
|
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 28.11.2011, 18:27 Titel: |
|
|
| Eternal_pain hat Folgendes geschrieben: | | hm.. hätte man eigentlich gleich drauf kommen können :S |
Nein, hätte man nicht, denn eigentlich sollte auch der Original-Code funktionieren. Von daher ist das keine Lösung, sondern ein Workaround für einen potentiellen Bug.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 28.11.2011, 18:48 Titel: |
|
|
Den Bug haben wir mittlerweile an die Entwickler weitergegeben.
Eternal_pain: kannst du einen Beispielcode für den von dir genannten Fehler erstellen, dann geben wir das auch gleich weiter. |
|
| Nach oben |
|
|
Eternal_pain
Anmeldungsdatum: 08.08.2006
Beiträge: 1783
Wohnort: BW/KA
|
| Verfasst am: 28.11.2011, 21:38 Titel: |
|
|
vom prinzip in etwa sowas...
hier kam es aber bisher zu keinem fehler, evtl. wurde es aber auch schon behoben.
Der fehler war mal vor einigen Versionen aufgetreten wenn man wie hier im beispiel
häufiger den neuen speicherbereich per reallocate der alten variable so übergab
und konnte auch durch das 'temp-workaround ' 'umgangen' werden...
| Code: |
dim mymem as integer ptr
mymem = callocate( sizeof(integer) )
Dim as integer i, l
do
l = int(rnd*1000)
mymem[i] = l
?mymem[i]
i += 1
mymem = reallocate( mymem, (i+1) * sizeof(integer) )
loop until asc(inkey) or (i = 100000)
deallocate (mymem)
|
_________________
|
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
