Compiler compiled nicht und ein Problem mit USESCREEN

[Schnatterplatsch]

Hattet ihr das auch schon? Das man F5/Starten klickt, der Compiler auch anscheinend compiliert(am Protokoll unten zu sehen), dann aber doch die Kopie des programmes gestartet wird? Bei mir compiliert er erst dann neu, wenn man den debugger aus, bzw. wieder anschaltet. Passiert nicht immer, sondern zuf?llig, was die Sache nat?rlich noch nerviger macht.

Au?erdem funktionieren bei mir transparenzen nicht mehr sobald ich einmal auf einen CREATESCREEN umgeschaltet habe(und mit USESCREEN -1) wieder zur?ck, nat?rlich. Auch ein erneutes SETTRANSPARENCY rgb(255,0,128) ?ndert nichts.

Wenn Bedarf besteht, dann schreib ich das zweite Problem nochmal raus, das war bisher nur eine fl?chtige Beobachtung

EDIT1:schau ich mir gerade nochmal an. So einfach wie oben beschrieben scheints nicht zu sein


EDIT2: Dr?cken wirs mal so aus: Ich hab ein Programm, das folgendes macht "transparente" Fl?che zeichnen(rgb(255,0,128)) drauf ein rotiertes sprite, dann grabsprite und irgendwann mal dan auch wieder drawsprite. solange ich keine usescreen dazwischenschalte funktionierts. Sobald aber ein Usescreen X% und ein usescreen -1 drinne sind siehts so aus:








EDIT3: also hier scheint das problem zu liegen, siehe Temp.rar.



[attachment deleted by admin]

[Schnatterplatsch]

wirklich niemand?

hab da n?mlich noch was: ein pl?tzlich(nach mehreren Erfolgreichen Hauptschleifen durchg?ngen) auftauchendes

"Microsoft Visual c++ runtime library" - error fenster

"The application has requestet the Runtime to terminate in an unusual way"


Bin ich da auch der einzige? Woher k?nnte dieser Fehler kommen? ich such zwar auch selber flei?ig, aber bis jetzt erfolglos.

[Kitty Hello]

Puh ist das kompliziert.
Ich kann den Fehler nachvollziehen.
GRABSPRITE in USESCREEN schint irgendwie nicht zu funktionieren. Schau mal Sprite 3 an, das sieht merkw?rdig aus.
Aber ich versteh' das eh' nicht. Du machst das ja doppelt.

Wenn Du ein Sprite drehen willst, mach doch so:

Code (glbasic) Select Expand




LOADSPRITE "observer2.bmp",0

MkRot(0,1,45)
MkRot(0,2,75)

DRAWSPRITE 1,0,0
DRAWSPRITE 2,100,0
SHOWSCREEN
MOUSEWAIT
END



FUNCTION MkRot: id_in%, id_out%, phi
LOCAL sx%, sy%
GETSPRITESIZE id_in%, sx%, sy% // hier sx*1.42, sy*1.42, damit nichts abgeschnitten wird. 1.42=sqrt(2)
CREATESCREEN 0, id_out, sx, sy
USESCREEN 0
ROTOSPRITE id_in, 0,0, phi // statt 0,0 hier sx*0.24, also (1.42 - 1)/2
USESCREEN -1
ENDFUNCTION


[Schnatterplatsch]

Danke, ich werds mal so probieren.


Zum Runtime-Problem: Habe einen Microsoft-Hotfix ausprobiert,(http://support.microsoft.com/kb/884538) was aber NICHTS gebracht hat.

Wenn ein Programm compiliert wurde und der Fehler tritt auf, scheint er immer an der gleichen Stelle aufzutreteten. F?gt man jetzt irgendwo eine Zeile Code hinzu, und compiled neu, tritt er sp?ter/fr?her auf.  Kann den Code des Programms hier leider nicht reinstellen, versuche aber nat?rlich weiter den Fehler zu sondieren. Einmal trat er beim Aufruf einer Function auf, in der

1. ein REDIM eines Types gemacht wurde.
2. ein paar type-variablen ein Wert zugewiesen wurden.

Komischerweise funktionierte die selbe Function davor bereits ein paarmal. Hab sie gel?scht, compiliert, eingef?gt, compiliert, ->> function wird fehlerfrei akzeptiert, Fehler daf?r aber woanders. Arrgh.



Neuer Fehler: Ein paar mal erhielt ich die Fehlermeldung "Keine Datei", als ich mit

LOADSPRITE "",sprite

einen Sprite-Speicherplatz ?berschreiben wollte. Laut Hilfe geht das aber.

[Kitty Hello]

Wo kommt die Fehlermeldung "Keine Datei"? Bricht der Debugger ab!? Dann mach lieber GRABSPRITE id, 0,0,0,0 oder so...

Ohne einen nachvollziehbaren Absturz kann ich schwer was pr?fen.

[Schnatterplatsch]

Jo, ich wei?, passierte 2/3 mal v?llig willk?rlich....

Das mit der runtime hat sich gekl?rt, ich schreib nochmal genau raus, was da war.

Zum nicht-compilen: der compiler geht ganz normal durch, und startet dann ganz normal.
...aber eben nur die Kopie!

[Kitty Hello]

Du dr?ckst aber nicht den gelben Knopf?

[Schnatterplatsch]

  ich doch nicht


aber hier stimmt irgendwas nicht:

DIM feld[0][0][0]
REDIM feld[2][2]

DEBUG BOUNDS(feld[],0)+"\n"
DEBUG BOUNDS(feld[],1)+"\n"
DEBUG BOUNDS(feld[],2)+"\n"

feld[1][0][1000]=50

DEBUG feld[1][0][1000]+"\n"

erzeugt folgende Ausgabe:

2
2
0
50

Bei ?hnlichem kam dieser Runtime error. Hier sagt aber nichtmal der compiler was

[Kitty Hello]

In der Debug Version sollte der aber meckern.
Du solltest schon wissen ob ein Feld 1D, 2D oder 3D ist.

[Schnatterplatsch]

Ist doch die debug-Version, sonst w?rde ja die Ausgabe nicht kommen, oder?

...und normalerweise wei? ich auch um die gr??e meiner arrays. Aber an sowas kann man sich dumm und d?mlich suchen, deswegen hab ichs mal gesagt.

[Schnatterplatsch]

hi nochmal. der 256 zeichen font ging auf dem wiz nicht. der kleine scheint zu gehen

[Schranz0r]

W?rdest du bitte f?r neue Probleme neue Threads aufmachen? 
Sonst ein wenig un?bersichtlich 

Dank dir.

Zum Thema:

Hmm, den kleinen Zeichensatz nimmt er den gro?en nicht?
H?rt sich aber komisch an...
Kann das einer best?tigen?

[Kitty Hello]

Schnatterplatsch: Wie gro? war der 256er Font? (in Pixeln)