Aaalso, ihr habt ja alle wieder schön kompakte Beiträge geschrieben...
Ich persönlich finde auch das Schwarze Balken oben und Unten auf 4:3 einen Gewissen Stil haben...
Den Screen würde ich dann immer einfach in der Desktopauflösung öffnen, die müsste ja in der Regel die richtige sein, und dann halt einfach alles aufzoomen, wie ZeHa schrieb kann man das auf viele Weisen lösen, kommt sicher auch aufs Genre an, bei Gloomy Nights & Living Dead hat man ja die perfekte Möglichkeit zum Zoomen, da ich auch ein ähnliches Spiel in Retrografik machen will werd ich das auch so umsetzen, nur eben mit 16:10 Verhältnis, Grad bei so geringen Auflösungen ist es wichtig selbst zu Zoomen und keine Optionen von Grafikkarte oder Bildschirm arbeiten zu lassen, weil das dann in der Regel einfach nur Matsch wird, man muss außerdem immer vom nicht versierten Nutzer ausgehen der vll nichma weis welche Auflösung sein Desektop überhaupt hat...
über Bildschirmseitenverhältnisse
Bei Gloomy Nights (320x240, 4:3) hab ich in der aktuellsten Version folgende Strategie:
- Desktop-Auflösung verwenden
- Bild so groß wie möglich zoomen, ohne daß interpoliert wird (z.B. auf 960x720 bei 1024x768)
- Bild zentriert darstellen, der Rest ist schwarz.
Funktioniert somit natürlich auch perfekt bei Widescreen, nur daß man halt dann links und rechts 'nen Balken hat. Macht man sein Spiel von Anfang an mit Widescreen-Design, dann haben nur die 4:3-Benutzer oben und unten 'nen Balken.
Diese Funktionalitäten hab ich damals in meine Wuro Game Lib eingebaut (siehe Spiele-Unterforum), hab zwar seitdem wenig Zeit gehabt, dran weiterzumachen, aber zumindest das mit der Auflösung funktioniert schon.
Es gibt aber leider Rechner, bei denen die Framerate dann extrem sinkt, weil manche Grafikkarten das Zoomen (mit Sprite3D) irgendwie nicht packen... keine Ahnung warum, aber ich denke mal auf allen neueren Maschinen dürfte das dann auch kein großes Problem mehr sein. Auf einer GeForce 5500 hab ich das aber mal getestet, da war's übel langsam (Monitor hatte 1600x1200, das Sprite wurde also auf die volle Größe gezoomt).
- Desktop-Auflösung verwenden
- Bild so groß wie möglich zoomen, ohne daß interpoliert wird (z.B. auf 960x720 bei 1024x768)
- Bild zentriert darstellen, der Rest ist schwarz.
Funktioniert somit natürlich auch perfekt bei Widescreen, nur daß man halt dann links und rechts 'nen Balken hat. Macht man sein Spiel von Anfang an mit Widescreen-Design, dann haben nur die 4:3-Benutzer oben und unten 'nen Balken.
Diese Funktionalitäten hab ich damals in meine Wuro Game Lib eingebaut (siehe Spiele-Unterforum), hab zwar seitdem wenig Zeit gehabt, dran weiterzumachen, aber zumindest das mit der Auflösung funktioniert schon.
Es gibt aber leider Rechner, bei denen die Framerate dann extrem sinkt, weil manche Grafikkarten das Zoomen (mit Sprite3D) irgendwie nicht packen... keine Ahnung warum, aber ich denke mal auf allen neueren Maschinen dürfte das dann auch kein großes Problem mehr sein. Auf einer GeForce 5500 hab ich das aber mal getestet, da war's übel langsam (Monitor hatte 1600x1200, das Sprite wurde also auf die volle Größe gezoomt).
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
Sprites ....
da sind wir wieder beim Problem.
Ich wollte ja mal meine Listen in Listen machen und damit dann eine
vernünftige Spriteverwaltung, die sich um solche Probleme kümmert.
Wir sollten Spiele ja nicht nur für HighEndGrafikkarten optimieren, sondern
auch an die mobilen stromsparenden Geräte denken.
Mein NoteBook zum Beispiel mit einer SiS 64 MB Grafikkarte kann
256 32 x 32 Sprites schneller darstellen als ein 512 x 512 Sprite
Das heißt, wenn man große Sprites in kleine aufteilt, läuft es besser.
Beim Zommen und Rotieren kann es natürlich zu unschönen leichten
Pixelüberschneidungen kommen.
Hier wäre ein Sprite-Mangement super. Noch besser wäre natürlich,
wenn PureBasic das im Hintergrund einfach implementiert hat und man
sich als Benutzer von PureBasic keinen Kopf mehr um folgende Problme
machen muss:
- nehme ich große oder viele kleine Sprites
- mache ich sie Quadratisch oder wenigstens mit Breite und Höhe durch 16 teilbar
- nehme ich komplett freie Größen bei Sprites
>>>>>>>>>>>>>>>>>>>
Ich weiß ja auch nicht, wer dafür verantwortlich ist.
- Grafikkarte?
- DirectX?
- Compiler?
- Programmierer?
>>>>>>>>>>>>>>>>>>>>
da sind wir wieder beim Problem.
Ich wollte ja mal meine Listen in Listen machen und damit dann eine
vernünftige Spriteverwaltung, die sich um solche Probleme kümmert.
Wir sollten Spiele ja nicht nur für HighEndGrafikkarten optimieren, sondern
auch an die mobilen stromsparenden Geräte denken.
Mein NoteBook zum Beispiel mit einer SiS 64 MB Grafikkarte kann
256 32 x 32 Sprites schneller darstellen als ein 512 x 512 Sprite
Das heißt, wenn man große Sprites in kleine aufteilt, läuft es besser.
Beim Zommen und Rotieren kann es natürlich zu unschönen leichten
Pixelüberschneidungen kommen.
Hier wäre ein Sprite-Mangement super. Noch besser wäre natürlich,
wenn PureBasic das im Hintergrund einfach implementiert hat und man
sich als Benutzer von PureBasic keinen Kopf mehr um folgende Problme
machen muss:
- nehme ich große oder viele kleine Sprites
- mache ich sie Quadratisch oder wenigstens mit Breite und Höhe durch 16 teilbar
- nehme ich komplett freie Größen bei Sprites
>>>>>>>>>>>>>>>>>>>
Ich weiß ja auch nicht, wer dafür verantwortlich ist.
- Grafikkarte?
- DirectX?
- Compiler?
- Programmierer?
>>>>>>>>>>>>>>>>>>>>
Kinder an die Macht http://scratch.mit.edu/
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
Vorschlag!
Wir setzen uns alle mal zusammen und beheben die Grundprobleme
der Spieleentwicklung unter PureBasic.
Denn egal wer ein Spiel mit PureBasic erschaffen möchte,
muss sich ja immer wieder mit den gleichen Problemen neu rumschlagen,
die aber eigentlich noch nicht das Kernproblem, also das Spiel beinhalten.
Einfach nur ne Spriteverwaltung, die auch die Auflösungen und Seitenverhältnisse berücksichtigt.
Erstmal als Include und später nativ in PureBasic integriert.
Wir setzen uns alle mal zusammen und beheben die Grundprobleme
der Spieleentwicklung unter PureBasic.
Denn egal wer ein Spiel mit PureBasic erschaffen möchte,
muss sich ja immer wieder mit den gleichen Problemen neu rumschlagen,
die aber eigentlich noch nicht das Kernproblem, also das Spiel beinhalten.
Einfach nur ne Spriteverwaltung, die auch die Auflösungen und Seitenverhältnisse berücksichtigt.
Erstmal als Include und später nativ in PureBasic integriert.
Kinder an die Macht http://scratch.mit.edu/
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
-
KeyKon
- Beiträge: 1412
- Registriert: 10.09.2004 20:51
- Computerausstattung: Laptop: i5 2,8 Ghz, 16GB DDR3 RAM, GeForce 555GT 2GB VRAM
PC: i7 4,3 Ghz, 32GB DDR3 RAM, GeForce 680 GTX 4GB VRAM
Win10 x64 Home/Prof
PB 5.30 (64bit) - Wohnort: Ansbach
- Kontaktdaten:
Dann schreib ma wenn du fertig bist...Xaby hat geschrieben:Vorschlag!
Wir setzen uns alle mal zusammen und beheben die Grundprobleme
der Spieleentwicklung unter PureBasic.
Denn egal wer ein Spiel mit PureBasic erschaffen möchte,
muss sich ja immer wieder mit den gleichen Problemen neu rumschlagen,
die aber eigentlich noch nicht das Kernproblem, also das Spiel beinhalten.
Einfach nur ne Spriteverwaltung, die auch die Auflösungen und Seitenverhältnisse berücksichtigt.
Erstmal als Include und später nativ in PureBasic integriert.
(\/) (°,,,°) (\/)
Mach aber vorher erst noch Deine Iso-Engine fertig 
(siehe http://www.purebasic.fr/german/viewtopi ... sc&start=0)
@ Kaeru: Ich weiß jetzt leider gar nicht mehr, womit ich es damals kompiliert habe, aber da war eh noch 4.20 aktuell, weißt Du zufällig ob da noch das alte DX7-Subsystem aktiv war?
(siehe http://www.purebasic.fr/german/viewtopi ... sc&start=0)@ Kaeru: Ich weiß jetzt leider gar nicht mehr, womit ich es damals kompiliert habe, aber da war eh noch 4.20 aktuell, weißt Du zufällig ob da noch das alte DX7-Subsystem aktiv war?
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.