FreeProfan

RGH (12.03.13)

Und wieder eine neue Version hochgeladen. Verbesserungen beim OGL-Testmode, bei Create("hpic",0,"&OGLBMP")

Leider finde ich immer noch einen Computer, auf dem der TestMode bei 17% abstürzt
sobald auf dem Kubus getestet wird. Für die oglbmp-Situation hat sich etwas geändert -
auf manchen Computern wo es zuvor ein kein Bild gab, wird jetzt das Bild erzeugt,
aber auf 3 von 5 Computern leider nicht.

RGH

Hm, wegen des Absturzes: Ich werde Dir heute Abend noch mal so zwei, drei Varianten zur Verfüung stellen und dich um zügige Tests bitten. Aber so langsam gehen mit die Ideen aus.

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

So machen wirs.

Vlt. einfach mal den TestMode als XProfan-Code programmieren?

Man wenn ("wenigstens") zuverlässig das OGL-BMP erhalten könnte dann könnte man
sich auch einen eigenen TestMode programmieren nach dem Verfahren was ich mal
beschrieben hatte. Du meintest zwar das es langsam wäre aber ich glaube das es
sogar schneller sein könnte wenn man viele Bereiche auf einmal testen möchte und es
hätte nicht diesen Verschiebe-Bug denn was nutzt ein nicht-abstürzender TestMode
der ein falsches Ergebnis liefert.

RGH

Tja, wenn das mit dem &OGLBMP schon nicht sicher klappt ...

Aber ok, hier die drei versprochenen Testversionen A, B und C:

A: [...]

B: [...]

C: [...]

Ich bin gespannt. Die Hoffnung stirbt zuletzt.

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

Bezogen auf den TestMode leider keine Änderung,

auf der HD4000 Karte wird nach wie vor der Kubus an falscher Stelle erkannt und
auf 2 Computern gibts einen Absturz beim Kubus.

oglbmp wiederum klappt bei allen 3 Versionen, kopiert aber leider nur Sichtbares
und nicht etwa nur den Inhalt des Statics auf dem OGL initialisiert ist.
Kompilieren Markieren Separieren

ogl.wnd=create("Static",hWnd,,,xx,yy)
ogl("init",ogl.wnd,getrvalue(col)/255,getgvalue(col)/255,getbvalue(col)/255,lightmode)

Besonders wenn das Hauptfenster nachträglich verkleinert wird fällt es auf, denn
dann hat man Desktop im Bild.

Dabei gibt es doch programme die OGL rein im Hintergrund rendern und erst per
BitBlit das Ergebnis auf einen sichtbaren DC kopieren. Wie machen die denn das?

Wenn wenigstens oglbmp immer richtig funktionieren würde wenn das
ogl.static auch mit showwindow(0) ausgeblendet ist, dann könnte man sich einen
eigenen TestModus schaffen der immer korrekt erkennt.

Vielleicht kannst Du ogl.init und show insofern ändern, als das eben nie auf einen
sichtbaren Bereich initialisiert wird sondern immer auf einen unsichtbaren und Du
kopierst bei ogl.show erst das Ergebnis auf den Schirm der bei ogl.init angegeben
wurde.

RGH

iF (14.03.13)

Bezogen auf den TestMode leider keine Änderung, auf der HD4000 Karte wird nach wie vor der Kubus an falscher Stelle erkannt und auf 2 Computern gibts einen Absturz beim Kubus.

Hier wäre ganz wichtig (!) zu wissen: An welcher Stelle erfolgt der Absturz bei welcher Version (A, B oder C)? Erfolgt er immer erst, wenn es einen Treffer gibt? Ich habe einen Rechner, auf dem liefert C gar keinen Treffer.

So langsam habe ich das Gefühl, dass der oder die betreffende/n Rechner eine oGL-Installation haben, die das Feature des SelectBuffers zum ermitteln der Hits nicht unterstützen oder es irgendwo in den Einstellungen ausgeschaltet haben. Haben sie ein dedizierte Grafikkarte, die oGL-Fähig ist oder nur eine schwachbrüstige Onboard-Grafik?

Funktioniert auf den Rechnern das Planetendemo (auf Planeten, Sonne, Mond, Hintergrund klicken, um in der Titelzeile zu sehen, was angeklickt wurde)?

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

>> Funktioniert auf den Rechnern das Planetendemo (auf Planeten, Sonne, Mond,
>> Hintergrund klicken, um in der Titelzeile zu sehen, was angeklickt wurde)?

Das funktioniert nach wie vor genau so wie Dein und mein TestMode-Test,
entweder geht es, stürzt ab, testet ebenso ungenau. So können wir also bei
Deinem und meinem TestMode-Test-Programm bleiben.

>> Hier wäre ganz wichtig (!) zu wissen: An welcher Stelle erfolgt der Absturz bei
>> welcher Version (A, B oder C)? Erfolgt er immer erst, wenn es einen Treffer gibt?

Ich schrieb ja:

auf der HD4000 Karte wird nach wie vor der Kubus an falscher Stelle erkannt und
auf 2 Computern gibts einen Absturz beim Kubus.

So langsam habe ich das Gefühl, dass der oder die betreffende/n Rechner eine oGL-Installation haben, die das Feature des SelectBuffers zum ermitteln der Hits nicht unterstützen oder es irgendwo in den Einstellungen ausgeschaltet haben. Haben sie ein dedizierte Grafikkarte, die oGL-Fähig ist oder nur eine schwachbrüstige Onboard-Grafik?

Auf 1 Computer mit schwacher Onboard-Grafik stürzt es ab;
auf 1 Computer mit schwacher Onboard-Grafik funktioniert es;
auf 1 Computer mit starker Onboard-Grafik funktioniert es
auf 1 Computer mit starker Onboard-Grafik kein Absturz aber Test ungenau/
bzw. nicht zu gebrauchen;
auf 1 Computer mit starker extra NVidia stürzt es ab.

Abstürze, wenn, immer erst beim Kubus.

>> Haben sie ein dedizierte Grafikkarte, die oGL-Fähig ist oder nur eine
>> schwachbrüstige Onboard-Grafik?

Scheint also nicht relevant zu sein. OGL-Programme von Google stürzen auf
keinem dieser Computer ab und deren TestMode funktioniert immer -
natürlich können die den ganz anders Programmiert haben was mich aber
wieder zu dem Thema führt auf das Du nicht so eingehst:

Vielleicht kannst Du ogl.init und show insofern ändern, als das eben nie auf einen
sichtbaren Bereich initialisiert wird sondern immer auf einen unsichtbaren und Du
kopierst bei ogl.show erst das Ergebnis auf den Schirm der bei ogl.init angegeben
wurde.

Der Sinn ist, dass eben dann ganz anders herangegangen werden könnte; ohne
den TestModus und ohne das er den Kubus an falschen Stellen findet.

Dann könnte man einfach das Licht und Blend/ AntiAlias abschalten und jedem
Objekt eine Farbe/ Name geben und GetPixel würde korrekt zurückliefern.

Da das Rendern scheinbar ja auf jedem Computer funktioniert wäre dies doch
eine sichere Variante.

RGH

iF (14.03.13)

Vielleicht kannst Du ogl.init und show insofern ändern, als das eben nie auf einen
sichtbaren Bereich initialisiert wird sondern immer auf einen unsichtbaren und Du
kopierst bei ogl.show erst das Ergebnis auf den Schirm der bei ogl.init angegeben
wurde.

Tja, da sind wir beim Problem von &OGLBMP, dass das Kopieren des OGL-Bildes, z.B. mit BitBlt, nicht funktionieren will. Das schafft ja Dein Testprogramm mit dem MemCopy auch nicht. Solltest Du hier eine Löung fuinden, kann ich sie übernehmen. Die OpenGL-API kann ja auch in Profan direkt aufgerufen werden. Theoretisch ließe sich so auch ein Testmodus selbst programmieren.

Ich bin geneigt, das Thema erst mal hintan zu stellen, zumal es offensichtlich nur sehr selten (exakt auf Deinen zwei genannten Rechnern) Probleme macht. Wenn ich aber noch Ideen habe, gebe ich Bescheid.

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

RGH

Noch ein Versuch:

Testversion D:

[...]

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

15.03.2013 ▲

RGH (14.03.13)

Ich bin geneigt, das Thema erst mal hintan zu stellen, zumal es offensichtlich nur sehr selten (exakt auf Deinen zwei genannten Rechnern) Probleme macht.

Das verstehe ich, ist ja auch nervig das Thema. Das das Problem nur sehr selten z.B.
nur auf meinen zwei genannten Rechnern auftritt, stimmt leider aber nicht, denn ein
größer angelegter Test in 2009 von einem Spiel von mir - gepostet in einem
Skype-Forum - hatte mich das Problem erst klar werden lassen, denn die dort
übermittelten Infos von 85 Testern ergaben, dass genau 25 Tester es überhaupt
Spielen hätten können, weil die meisten einen Absturz hatten oder die von mir
programmierte Meldung, dass der TestMode nicht funktioniert. Auch von RedCube
erhalte ich heute noch ständig E-Mails, dass sie das Spiel nicht spielen können,
weil die Klicks falsch erkannt werden oder es abstürzt. Erst danach stellte ich auf
eigenen anderen Computern fest, dass auch dort der TestMode sich verhält wie
heute.

Aus diesem Grund halte ich mittlerweile einige größere und eigentlich recht tolle
aber nun auch schon wieder ein paar Jahre alte Spiele zurück, weil ich weiß,
dass die Mehrzahl sie ja garnicht spielen können und wer postet schon gerne
ein Programm, dass nicht einmal auf den eigenen Computern richtig funktioniert.

Auch sehr schön testen, wo der TestMode gut funktioniert und wo nicht, kann man mit
Okrea ( [...]

) wo ich mich beim Vorzeigen des Programmes bei Freunden, auch oft
wunderte, warum die Erkennung unterm Mauspfeil recht ungenau war.

Was ich besonders schade finde, ist, dass auf meinem neuen Computer der TestMode
solch Murx zurückliefert und den Kubus falsch erkennt, nun also wieder die Spiele
nicht weiter programmieren kann.

Version D liefert auf dem Absturzrechner auch einen Absturz und erkennt auf
dem I7 mit HD4000 nach wie vor den Kubus an falscher Stelle.

Ich lasse das Thema jetzt aber einfach mal sein und nerve nicht weiter damit.

15.03.2013 ▲

RGH

iF (15.03.13)

Version D liefert auf dem Absturzrechner auch einen Absturz und erkennt auf
dem I7 mit HD4000 nach wie vor den Kubus an falscher Stelle.

Wie falsch? Nur ein Schatten drumherum, aber in den richtigen Ausmaßen oder schlimmer?
Das mit dem Absturz ist mir ein absolutes Rätsel. Vieleicht bastele ich noch mal eie Debug-Version mit ein paar Debug-Ausgaben. Es muss doch einen Grund haben, das auf den SelectBuffer nicht zugegriffen werden kann ...

Gruß
Roland

XProfan X2
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4

15.03.2013 ▲