Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Nanu? - Neue Fehlermeldung
Gehe zu Seite 1, 2  Weiter
 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu QBasic.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 14:55    Titel: Nanu? - Neue Fehlermeldung Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
isiprimax



Anmeldungsdatum: 02.01.2009
Beiträge: 77

BeitragVerfasst am: 23.04.2009, 15:51    Titel: Antworten mit Zitat

Ohne Code kann man schlecht helfen.

Jetzt so ins Blaue geraten wuerd ich sagen, Speicher wird nicht richtig entleert.

mfg
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 16:09    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 16:10    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 16:43    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 16:58    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 17:00    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 23.04.2009, 17:16    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 17:23    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 17:32    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 17:37    Titel: Antworten mit Zitat

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) / cool * 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
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 17:42    Titel: Antworten mit Zitat

Aus der QB-Hilfe. Zunge rausstrecken 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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 17:55    Titel: Antworten mit Zitat

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! Zunge rausstrecken
Cool, dein Code hat funktioniert, jetzt klappt es! grinsen
Tausend Dank! vor Freude klatschen
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 18:46    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 19:24    Titel: Antworten mit Zitat

Damit gehts nicht mehr. Hab ich erwähnt dass das in Screen 7 läuft? Hat das vielleicht damit zu tun?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 19:41    Titel: Antworten mit Zitat

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. Zunge rausstrecken
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
dreael
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 2529
Wohnort: Hofen SH (Schweiz)

BeitragVerfasst am: 23.04.2009, 20:15    Titel: Antworten mit Zitat

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
Code:
DIM feld(...)

statt
Code:
DIM feld%(...)

schreibst, ohne dass es zu Beginn ein
Code:
DEFINT a-z

gibt, dann macht QB automatisch ein unsichtbares
Code:
DEFSNG a-z

am Anfang, womit ein
Code:
DIM feld!(...)

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
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
MalteF



Anmeldungsdatum: 04.12.2008
Beiträge: 44

BeitragVerfasst am: 23.04.2009, 22:19    Titel: Antworten mit Zitat

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
Code:
DIM feld(...)

statt
Code:
DIM feld%(...)

schreibst, ohne dass es zu Beginn ein
Code:
DEFINT a-z

gibt, dann macht QB automatisch ein unsichtbares
Code:
DEFSNG a-z

am Anfang, womit ein
Code:
DIM feld!(...)

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. mit dem Kopf durch die Mauer wollen

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
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 23.04.2009, 22:48    Titel: Antworten mit Zitat

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. Zunge rausstrecken
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
St_W



Anmeldungsdatum: 22.07.2007
Beiträge: 956
Wohnort: Austria

BeitragVerfasst am: 23.04.2009, 22:58    Titel: Antworten mit Zitat

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
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu QBasic. Alle Zeiten sind GMT + 1 Stunde
Gehe zu Seite 1, 2  Weiter
Seite 1 von 2

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz