| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
 Verfasst am: 23.04.2009, 14:55 Titel: Nanu? - Neue Fehlermeldung |
 |
|
Nach all den Jahren doch noch mal ne neue Fehlermeldung kennengelernt:
DOS Speicherbereichfehler
Speicherzuordnungsfehler
COMMAND kann nicht geladen werden, System angehalten
Tritt immer dann auf, wenn ich mein Programm zum zweiten Mal ausführe.
Das erste Mal läuft's ohne Probleme, beim zweiten Mal obige Fehlermeldung.
Reicht das schon um zu ahnen wo der Fehler liegt, oder soll ich noch den Code posten? |
|
| Nach oben |
|
 |
isiprimax
Anmeldungsdatum: 02.01.2009
Beiträge: 77
|
| Verfasst am: 23.04.2009, 15:51 Titel: |
|
|
Ohne Code kann man schlecht helfen.
Jetzt so ins Blaue geraten wuerd ich sagen, Speicher wird nicht richtig entleert.
mfg |
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 16:09 Titel: |
|
|
Okay, also was das ganze darstellen soll:
Der Anfang einer Grafikadventure Engine. Ein Hintergrundbild (breiter als 320px, eingeteilt in 8px breite Spalten) wird dargestellt und gescrollt (mit versetzter Start-Spalte neugezeichnet) sobald die Bildschirmposition des Spielersprites <64 oder >256 ist. Die Spalten werden alle ins selbe Datenfeld, ans selbe Offset geladen...
| Zitat: |
StartSpalte = INT(MaxSpalte / 2) - 20
GOSUB ZeichneSpalte
DO: c$ = INKEY$
IF c$ = "a" THEN
PlayerXPos = PlayerXPos - 2
PlayerScreenPos = PlayerXPos - ScreenXStart
IF PlayerScreenPos < 64 AND StartSpalte > 1 THEN StartSpalte = StartSpalte - 1: GOSUB ZeichneSpalte
END IF
IF c$ = "d" THEN
PlayerXPos = PlayerXPos + 2
PlayerScreenPos = PlayerXPos - ScreenXStart
IF PlayerScreenPos > 256 AND StartSpalte < MaxSpalte - 40 THEN StartSpalte = StartSpalte + 1: GOSUB ZeichneSpalte
END IF
GOSUB Update
LOOP UNTIL c$ = CHR$(27)
END
Update:
SCREEN 7, , 2, 3
PCOPY 1, 2
ScreenXStart = StartSpalte * 8
PlayerScreenPos = PlayerXPos - ScreenXStart
LINE (PlayerScreenPos, 20)-(PlayerScreenPos, 60), 12, BF
PCOPY 2, 3
RETURN
ZeichneSpalte:
SCREEN 7, , 1, 3
FOR v = 0 TO 39
DEF SEG = VARSEG(Spalte%(0))
Namd$ = "Spalt" + LTRIM$(STR$(StartSpalte + v)) + ".img"
BLOAD Namd$, VARPTR(Spalte%(0))
PUT (v * 8, 20), Spalte%, PSET
NEXT v
RETURN
|
|
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 16:10 Titel: |
|
|
sicher, dass die grafik richtig mit BSAVE abgespeichert wurde?
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
 |
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 16:43 Titel: |
|
|
| Jojo hat Folgendes geschrieben: | | sicher, dass die grafik richtig mit BSAVE abgespeichert wurde? |
Würde sich ein Fehler dabei denn in so einer Fehlermeldung äußern?
Was kann ich denn da falsch machen?
Dargestellt wird die Grafik auf jeden Fall richtig... |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 16:58 Titel: |
|
|
Ja, kann er, weil du mit dem befehl direkt im speicher rumpopelst und da kann unter DOS so EINIGES schief gehen. Glaub mir, die ersten Gehversuche mit BLOAD/BSAVE haben meinen Rechner bei jedem Programmstart den Rechner neu gebootet.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 17:00 Titel: |
|
|
Tja, und was mach ich da nun? Geht in anderen Programmen ja auch..
Wenn der Fehler bei falsch benutzten BSAVE Befehlen liegt - wie mach ich's richtig? |
|
| Nach oben |
|
|
dreael
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)
|
| Verfasst am: 23.04.2009, 17:16 Titel: |
|
|
Zur Erinnerung: Reines MS-DOS kennt keinerlei Speicherschutz! Das heisst: Wird bei BLOAD und DEF SEG ein Müll berechnet, werden Speicherbereiche ausserhalb vom QB-Speicherbereich überschrieben. Somit stösst die CPU an durch die Überschreibung beschädigten Maschinencode (dies können in den Arbeitsspeicher geladene Teile von QBASIC.EXE selber sein, ebenso natürlich auch Teile vom COMMAND.COM oder gar MS-DOS-Kernel selber), womit ein Komplettabsturz resultieren kann.
In Windows kann logischerweise nur der NTVDM-Prozess auf diese Weise amok laufen, wenn sich ein fehlerhaftes 16-Bit-Programm im dort simulierten konventionellen Speicher austobt.
_________________
Teste die PC-Sicherheit mit www.sec-check.net |
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 17:23 Titel: |
|
|
Ich muss doch irgendwie verhindern können dass DEF SEG und BLOAD mir Müll berechnen? Oder irgendwie erkennen wenn sie nen Bereich adressieren wo sie nix verloren haben?
(Spielt das ne Rolle, dass ich das ganze unter WinXP laufen lasse?) |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 17:32 Titel: |
|
|
Es wäre interessant zu wissen, wie dein BSAVE-Kommando aussieht. Wenn dort z.B. eine falsche Menge Speicher gespeichert wird, wird auch u.U. wieder ne falsche Menge Speicher geladen.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 17:37 Titel: |
|
|
Das kann gut sein. Also das ist meine Speicher-SUB:
| Zitat: |
REM '$DYNAMIC
Bits = 1: Planes = 4
Y1 = 0
X2 = X1 + 7: Y2 = 140
Bytes = 4 + INT(((X2 - X1 + 1) * Bits + 7) /  * Planes * ((Y2 - Y1) + 1)
DIM Array%(Bytes)
DEF SEG = VARSEG(Array%(1))
GET (X1, Y1)-(X2, Y2), Array%(1)
BSAVE Nam$ + ".IMG", VARPTR(Array%(1)), Bytes
|
Weiß jetzt nicht mehr vorher ich die Formel hatte, die mir "Bytes = " berechnet.... |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 17:42 Titel: |
|
|
Aus der QB-Hilfe.  Und die ist zu Allgemein und in deinem Beispiel wohl auch falsch angewendet. Benutzt du wirklich einen Schwarz-Weiß-Grafikmodus (1 Bit?) Und warum fängst du mit dem Array-Index 1 an, wo das Array doch mit 0 beginnt?
Für screen 13 müsste das ungefähr so aussehen (Warnung, ich hab das seit jahren nicht mehr gemacht, keine garantie für richtigkeit):
| Code: |
'$Dynamic
screen 13
dim bytes as integer
bytes = 4 + Breite * Höhe 'hier die passenden Werte Eintragen
redim feld(0 to bytes - 1)
get(0,0)-(breite -1, höhe -1), feld(0)
def seg = varseg(feld(0))
bsave "datei", varptr(feld(0)), bytes
def seg
|
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 17:55 Titel: |
|
|
| Jojo hat Folgendes geschrieben: | | Und warum fängst du mit dem Array-Index 1 an, wo das Array doch mit 0 beginnt? |
Tja, so im Nachhinein frag ich mich das auch!
Cool, dein Code hat funktioniert, jetzt klappt es! 
Tausend Dank!  |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 18:46 Titel: |
|
|
hab noch einen kleinen fehler nach der bearbeitung entdeckt, natürlich muss es heißen:
| Code: | | redim feld(0 to (bytes - 1) \ 2) as integer |
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 19:24 Titel: |
|
|
| Damit gehts nicht mehr. Hab ich erwähnt dass das in Screen 7 läuft? Hat das vielleicht damit zu tun? |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 19:41 Titel: |
|
|
screen 7 hat nur 4 bit und nicht 8 bit farbtiefe. da müsste das sogar noch viel mehr laufen. kann aber sein, dass ich mich verrechnet hab. aber ein bisschen mehr speicher zu belegen ist auch nicht schlimm.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
dreael
Administrator
Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)
|
| Verfasst am: 23.04.2009, 20:15 Titel: |
|
|
Bei SCREEN 7 gilt: Breite immer aufs nächste Vielfache von 8 aufrunden bei der Berechnung der Arraygrösse, Rest mit 4 Bits pro Pixel ist vollkommen richtig. Ausserdem Zahlentyp beim Array beachten, d.h. wenn Du
statt
schreibst, ohne dass es zu Beginn ein
gibt, dann macht QB automatisch ein unsichtbares
am Anfang, womit ein
resultiert, d.h. Element belegt 4(!) statt nur 2 Bytes!
Sonst etliche dieser Details sind in der BMP-Bibliothek enthalten. Dort Quellcode von HoleBildInfo() beachten.
_________________
Teste die PC-Sicherheit mit www.sec-check.net |
|
| Nach oben |
|
|
MalteF
Anmeldungsdatum: 04.12.2008
Beiträge: 44
|
| Verfasst am: 23.04.2009, 22:19 Titel: |
|
|
| dreael hat Folgendes geschrieben: | Bei SCREEN 7 gilt: Breite immer aufs nächste Vielfache von 8 aufrunden bei der Berechnung der Arraygrösse, Rest mit 4 Bits pro Pixel ist vollkommen richtig. Ausserdem Zahlentyp beim Array beachten, d.h. wenn Du
statt
schreibst, ohne dass es zu Beginn ein
gibt, dann macht QB automatisch ein unsichtbares
am Anfang, womit ein
resultiert, d.h. Element belegt 4(!) statt nur 2 Bytes!
Sonst etliche dieser Details sind in der BMP-Bibliothek enthalten. Dort Quellcode von HoleBildInfo() beachten. |
Okay, mittlerweile das Datenfeld für das Spielersprite eingebaut, neues Problem, nur andere Fehlermeldung - beim 2. Durchlauf findet er angeblich eine Datei nicht. 
Aaalso, die Breite des Sprites ist ein vielfaches von 8. Höhe ist egal?
Wenn ich DIM feld% schreibe kann ich hinterher nicht AS INTEGER schreiben. Weglassen? |
|
| Nach oben |
|
|
Jojo
alter Rang
Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte
|
| Verfasst am: 23.04.2009, 22:48 Titel: |
|
|
Gewöhn dir Suffixe einfach gar nicht erst an und nimm lieber AS INTEGER/LONG/SINGLE/DOUBLE/whatever. und ja, höhe ist egal. und wenn eine datei nicht gefunden wird, dann wird sie eben nicht gefunden.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
|
|
| Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007
Beiträge: 956
Wohnort: Austria
|
| Verfasst am: 23.04.2009, 22:58 Titel: |
|
|
Wenn eine Datei nicht gefunden wird, könnte das auch daran liegen, dass entweder der Dateipfad länger als die maximal möglich Länge ist (ich glaub das waren 127 Zeichen) oder Umlaute oder sonstige nicht-Amerikanische Zeichen vorkommen. Bei letzterem sollte das natürlich nicht passieren, aber es kommt trotzdem öfters vor.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
