Dr. Wuro Game Library

[ZeHa]

Servus,

wie ich bereits ein paar mal angekündigt habe, arbeite ich zur Zeit an einer kleinen Game-Library, die einem das schnelle Erstellen eines Spiels ein wenig erleichtern soll. Es ist keine komplette Engine, sondern eher eine Sammlung von Funktionen, die einem lästige Arbeit abnehmen.

Die Lib ist sicherlich noch nicht als fertig zu betrachten, aber sie bietet bereits einige nützliche Dinge, und ich stelle sie u.a. auch deshalb vor, weil ich mir ein paar sinnvolle Feature Requests von euch erhoffe

Was momentan drin ist:
- Clean Pixel-Technologie! (scheint ja mittlerweile zu funzen)
- Unterstützung für animierte Sprites
- Unterstützung für Bitmap-Fonts
- ein paar nützliche Tool-Funktionen (FPS, Zeit, etc)

Was noch kommt:
- ...das liegt in eurer Hand

Download:
http://www.dr-wuro.com/games/wurogame.rar
- wurogame.pb (-> die Library)
- testgame.pb (-> ein kleines Beispiel)
- testgame.exe, man.bmp, wurofont.bmp (-> direkt ausprobieren )



Wenn das Projekt wachsen sollte (was ich hoffe), dann gibt's irgendwann auch eine etwas bessere Doku. Wer Lust hat, an der Lib Verbesserungen vorzunehmen oder Bugs zu fixen, der darf dies gerne machen, aber bitte kontaktiert mich dann. Ich bin noch nicht ganz sicher unter welche Lizenz ich es stellen soll, zum einen denke ich daß es BSD-mäßig ganz gut wäre, aber zum anderen fände ich es auch hübsch, wenn das offizielle Release immer alle tollen Features beinhaltet

Noch ein Hinweis: Aufgrund der "Clean Pixel"-Technologie ist die Lib natürlich eher für oldschoolige Spiele mit z.B. 320x240 ausgelegt. Falls jemand damit modernere Spiele machen will und dann irgendwie Probleme auftreten sollten, gebt mir einfach bescheid, evtl. kann man die Lib entsprechend umbauen, daß auch "normale" Modi möglich sind.

Und noch was zum Code: Die Funktionen WURO_initFullscreen() und WURO_initWindowed() beinhalten zum Teil viel gleichen Code. Mir ist das bewußt. War anfangs nicht so aber hat sich nun doch so ergeben. Ich wollte es noch umbauen aber irgendwie hatte ich jetzt doch keine Lust mehr wird dann beim nächsten Mal etwas hübscher gemacht...

Und noch was anderes zum Code: Das Error-Handling ist im Moment noch sehr Entwicklermäßig das Spiel beendet sich einfach mit 'ner für PB-User einigermaßen sinnvollen Bemerkung. Ich überlege aber wie ich das später etwas schöner machen kann. Wer Vorschläge hat, nur her damit.

[ZeHa]

Ach ja, stimmt, die WindowEvents() werden auch noch nicht abgearbeitet... hab das in der neuen Gloomy-Version zwar als Hack mit dringehabt, aber für die Lib weiß ich noch nicht ob es reinkommt. Ich denke aber daß es doch ganz sinnvoll wäre (z.B. in der WURO_flipBuffers()), da man andere WindowEvents innerhalb seines Spiels wahrscheinlich sowieso nicht überprüfen muß...

[gnasen]

So mal getestet, fangen wir mit dem negativen an:

Ich hatte mir von der CleanPixel Technologie mehr erhofft als den Screen zu grabben und passend zu zoomen (oder hab ich was übersehen?)
Zudem wären vernünftige deklarationen der Variablen hilfreich für Projekte mit EnableExplicit.

Und fahren mit dem guten fort:

Sehr einfach gehalten, braucht keine große Einarbeitung.
Schönen FPS zähler "onboard".
Das Laden von Animationen und, mein Lieblingsschmankerl, BitmapFonts.

Das ganze ist vorallem für Anfänger sehr gut zum lernen und könnte schon fast als Tutorial dienen, um viele der Anfängerfehler zu vermeiden. Zudem sehr sauber und übersichtlich gecoded, gefällt mir gut.
Ich hoffe die Lib wird noch weiter wachsen

[ZeHa]

Clean Pixel existiert nur aus diesem einen Grund Denn in heutigen Zeiten, wo es fast nur noch TFTs gibt, sehen oldschoolige Auflösungen wie 320x240 oft sehr unscharf aus. Da die Grafikkartentreiber bzw. Monitorhersteller aber keinen entsprechenden Modus anbieten, muß man halt hoffen, daß Spiele das selbst erledigen und genau drum hab ich das halt getan und in die Lib eingebaut (zur Erklärung: es wird auf eine "gerade" Auflösung gezoomt, also so, daß die Pixel alle gleich groß sind. Es wird z.B. nicht 320x240 auf 800x600 gezoomt (das wäre nicht sehr schön), sondern es wird dann nur auf 640x480 gezoomt. Und wenn Du 1024x768 hast, wird's auf 960x720 gezoomt. Ich halte das halt für den besten Kompromiß, denn der minimale Rand ist zu verschmerzen, dafür hat man halt ein astreines Bild)

Hier eine evtl. etwas bessere Erklärung, da ein paar Bilder mit dabei sind: http://www.purebasic.fr/german/viewtopi ... 001#208001

Mit den Deklarationen: Ich hab extra in meinem Code DisableExplicit angegeben, damit es zumindest für meine Datei nicht gelten muß
Aber Du hast natürlich Recht, und ich werde das noch umbauen... hatte nur bisher zu wenig Lust das komplett durchzuziehen, aber das wird dann definitiv im nächsten Update behoben sein

[nco2k]

ohne deine arbeit zunichte machen zu wollen, muss ich dir leider sagen, dass deine cleanpixel technologie imho schlecht umgesetzt wurde. da deine lib gerade für retro games gut geeignet ist und auf dementsprechend langsamen rechnern laufen soll, ist das ständige grabben und zoomen des screens, der absolut falsche weg. zudem ist UseBuffer() extrem langsam, sofern man irgendwann das dx9 subsystem verwenden möchte und daher sollte man diesen befehl niemals in einer schleife ausführen.

deswegen würde ich dir einen anderen weg vorschlagen... PurePixel!

Code: Alles auswählen

#AppName = ".:: PurePixel!  -  by nco2k"
#RenderWidth = 320
#RenderHeight = 240

If InitSprite() And InitKeyboard() And ExamineDesktops()
  
  DesktopWidth = DesktopWidth(0)
  DesktopHeight = DesktopHeight(0)
  
  Select MessageRequester(#AppName, "Fullscreen?", #MB_YESNOCANCEL | #MB_ICONQUESTION)
    
    Case #IDYES
      ShowCursor_(#False)
      WindowWidth = DesktopWidth
      WindowHeight = DesktopHeight
      WindowFlags = #PB_Window_BorderLess
      ScaleY = Int(WindowHeight / #RenderHeight)
      ScreenWidth = ScaleY * #RenderWidth
      ScreenHeight = ScaleY * #RenderHeight
      ScreenX = Int((WindowWidth - ScreenWidth) / 2)
      ScreenY = Int((WindowHeight - ScreenHeight) / 2)
      
    Case #IDNO
      ScaleY = Int((DesktopHeight - 128) / #RenderHeight)
      While ScaleY * #RenderWidth > DesktopWidth - 128
        ScaleY - 1
      Wend
      WindowWidth = ScaleY * #RenderWidth
      WindowHeight = ScaleY * #RenderHeight
      WindowFlags = #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_ScreenCentered
      ScreenWidth = WindowWidth
      ScreenHeight = WindowHeight
      ScreenX = 0
      ScreenY = 0
      
    Default
      End
      
  EndSelect
  
  If OpenWindow(0, 0, 0, WindowWidth, WindowHeight, #AppName, WindowFlags | #PB_Window_Invisible) And CreateGadgetList(WindowID(0))
    If ImageGadget(0, ScreenX, ScreenY, ScreenWidth, ScreenHeight, 0) And OpenWindowedScreen(GadgetID(0), 0, 0, #RenderWidth, #RenderHeight, #True, 0, 0)
      SetWindowColor(0, RGB(0, 0, 0))
      SetFrameRate(60)
      TransparentSpriteColor(#PB_Default, RGB(255, 0, 255))
      If LoadSprite(0, "C:\wurogame\man.bmp")
        HideWindow(0, #False)
        
        PosX = 96
        PosY = 88
        
        Repeat
          
          Repeat
            WinEvent = WindowEvent()
            If WinEvent = #PB_Event_CloseWindow
              Break 2
            EndIf
          Until WinEvent = 0
          
          ExamineKeyboard()
          If KeyboardPushed(#PB_Key_Up)
            PosY - 1
          EndIf
          If KeyboardPushed(#PB_Key_Down)
            PosY + 1
          EndIf
          If KeyboardPushed(#PB_Key_Left)
            PosX - 1
          EndIf
          If KeyboardPushed(#PB_Key_Right)
            PosX + 1
          EndIf
          
          ClearScreen(RGB(80, 100, 120))
          DisplayTransparentSprite(0, PosX, PosY)
          FlipBuffers()
          
        Until KeyboardPushed(#PB_Key_Escape)
        
      EndIf
    EndIf
  EndIf
  
EndIf : End

windowed screens verfügen über das nette autostretch feature und davon mache ich hier gebrauch. dadurch sollte das ganze deutlich schneller laufen, auf langsamen rechnern. im fenster modus ermittle ich die maximale grösse automatisch, so dass keine balken angezeigt werden müssen.

möglicher nachteil, der vollbild modus ist auch "nur" ein windowed screen, was imho nicht weiter schlimm ist. ansonsten finde ich die idee an deiner lib echt gut und ich hoffe, dass ich dir eventuell helfen konnte, sie noch besser zu machen.

ps: dein testgame hängt sich nach ein paar sekunden auf unter vista, da die window events nicht abgearbeitet werden. aber ich glaub das weisst du schon.

c ya,
nco2k

[Kaeru Gaman]

windowed screens verfügen über das nette autostretch feature und davon mache ich hier gebrauch. dadurch sollte das ganze deutlich schneller laufen, auf langsamen rechnern. im fenster modus ermittle ich die maximale grösse automatisch, so dass keine balken angezeigt werden müssen.

und genaus das ist, was CleanPixel umgehen will und tut!

einen gestretchten Windowedscreen kann jeder bauen, hat man meistens auch schon mal gemacht,
und mit dem Weichgerechne durch die Grafikkarte sieht es wirklich extrem bescheiden aus.

außerdem

da deine lib gerade für retro games gut geeignet ist und auf dementsprechend langsamen rechnern laufen soll

wer behauptet denn das?
es geht gerade darum, auf neueren rechnern, die 320x200 garnicht mehr nativ können
das dementsprechende Retro-Feeling zu erzeugen!

zudem ist UseBuffer() extrem langsam, sofern man irgendwann das dx9 subsystem verwenden möchte

wieso sollte usebuffer langsamer sein auf DX9? o_O

...abgesehen davon, könnte man das auch eliminieren.
es geht nur darum, dass das texsprite eine (2^n)² größe bekommt,
das könnte man auch gleich beim grabben so einstellen.

also...
> dass deine cleanpixel technologie imho schlecht umgesetzt wurde
weit gefehlt, sie tut genau wofür sie erschaffen wurde.
deine
> PurePixel
ist standard kalter Kaffe und reicht nicht ansatzweise an die vorgestellte Basisidee heran.

[nco2k]

@KG
vielleicht solltest du das nächste mal zuerst den code angucken/ausprobieren bevor du so viel müll auf einmal postest.

einen gestretchten Windowedscreen kann jeder bauen, hat man meistens auch schon mal gemacht,
und mit dem Weichgerechne durch die Grafikkarte sieht es wirklich extrem bescheiden aus.

bei meinem code wird nichts interpoliert! es geschiet genau das was cleanpixel auch tut, nur deutlich performanter.

es geht gerade darum, auf neueren rechnern, die 320x200 garnicht mehr nativ können
das dementsprechende Retro-Feeling zu erzeugen!

was spricht dagegen, die system anforderungen so minimal wie möglich zu halten?

wieso sollte usebuffer langsamer sein auf DX9? o_O

weil es so ist. die diskussion hatte ich mit fred schon mal als das dx9 subystem noch in der alpha phase war. fred meinte er kann da leider nichts machen. wenn du mir nicht glaubst, vergleiche selbst. bei mir läufts auf einem high end system mit stolzen 15-16fps.

Code: Alles auswählen

If InitSprite() And OpenWindow(0, 0, 0, 480, 360, "Test", #PB_Window_SystemMenu | #PB_Window_ScreenCentered) And OpenWindowedScreen(WindowID(0), 0, 0, WindowWidth(0), WindowHeight(0), 0, 0, 0) 
  
  If CreateSprite(0, 256, 256) 
    
    Repeat 
      
      Repeat 
        WinEvent = WindowEvent() 
        If WinEvent = #PB_Event_CloseWindow 
          Break 2 
        EndIf 
      Until WinEvent = 0 
      
      UseBuffer(0) 
      UseBuffer(-1) 
      ClearScreen(RGB(0, 0, 0)) 
      If StartDrawing(ScreenOutput()) 
        TimerCurrent = ElapsedMilliseconds() 
        If TimerCurrent > TimerFPS + 1000 
          TimerFPS = TimerCurrent 
          FPS = CounterFPS 
          CounterFPS = 0 
        Else 
          CounterFPS + 1 
        EndIf 
        DrawText(10, 10, "FPS: "+Str(FPS), RGB(255, 255, 255), RGB(0, 0, 0)) 
        StopDrawing() 
      EndIf 

      FlipBuffers(0) 
      
    ForEver 
    
  EndIf 
  
EndIf : End

ist standard kalter Kaffe und reicht nicht ansatzweise an die vorgestellte Basisidee heran.

tja wie gesagt, hättest du den code ausprobiert, hättest du festgestellt, dass es sehr wohl der basisidee entspricht.

c ya,
nco2k

[Kaeru Gaman]

> vielleicht solltest du das nächste mal zuerst den code angucken/ausprobieren bevor du so viel müll auf einmal postest.

selber müll, schmatzebobbes!

1. angeschaut habe ich mir den code.
ich sah keine anforderung an die Graka, ohne weichrechnen darzustellen.

2. nachdem du drauf bestehst, habe ich ihn auch mal ausprobiert.
ergebnis: es wird, wie ich mir dachte, sehr wohl weichgerechnet.
wie sollte es auch anders sein?

es ist völlig schnurz, ob du einen autostretched windowedscreen in ein
gadget oder in ein window packst, stretched ist streched!

glaubst du eigentlich, ich hätte noch nie einen autostrecht windowedscreen verwendet?
was meinst du denn, warum ich was zu dem thema sage?
weil ich weichgerechnete pixel so sehr liebe?



[edith]
hier, damit du mir auch glaubst:


...und wie ich bereits schrob, man kann auf das UseBuffer auch verzichten,
wenn man gleich beim grabben eine (2^n)² größe verwendet.

[ZeHa]

Ich mußte UseBuffer() benutzen, weil ich ansonsten im Windowed Mode nicht mehr grabben konnte (weil das gegrabbte Bild größer als das Window gewesen wäre).


@ nco2k: Ohne Deine Arbeit zunichte machen zu wollen muß ich Dir leider sagen, daß Deine PurePixel-Technologie imho nicht das bietet, was ich mit der Clean Pixel-Technologie erreichen wollte.

Kaeru hat recht, es geht nicht darum, "Retro"-Games auf alter Hardware hinzukriegen, denn dann kann ich ja einfach einen 320x240-Screen aufmachen und gut ist. Es geht darum, auf neuer Hardware, die oft kein 320x240 mehr kann und zudem meist mit einem TFT bestückt ist, wieder ein sauberes, oldschooliges Bild hinzubekommen.

Hier zwei Bilder mit Vergleich (habe Deinen Code ausprobiert und er interpoliert).
http://www.dr-wuro.com/games/purepixel_ ... npixel.png
http://www.dr-wuro.com/games/purepixel_ ... zoomed.png


Mag sein daß UseBuffer() langsam ist (hatte leider auch schon einen Rechner in der Hand, wo das nicht so super lief), aber eine bessere Möglichkeit konnte ich bisher einfach noch nicht finden. Wenn Du was besseres kennst, dann bin ich froh um jeden Vorschlag - nur sollte es dann halt auch das gewünschte Ergebnis liefern.



EDIT: Eine Möglichkeit wäre vielleicht, gar nicht erst auf den Screen zu zeichnen sondern gleich in den Buffer, der dann gezoomt wird. Allerdings muß ich mich dann auf die User der Lib verlassen können, daß sie zwischendrin nicht UseBuffer(#PB_Default) aufrufen. Das dürfte evtl. ein Problem darstellen.

[nco2k]

so siehts bei mir aus:


die idee war ja das vergrösseren anhand von pixelverdopplung, genauso wie es auch cleanpixel tut. bei mir wird ja auch weichgezeichnet wenn ich eine unpassende auflösung zum vergrössern auswähle, aber bei verdopplung 320x240 -> 640x480, 960x720 etc. wird alles sauber gestretcht wie man sieht. vielleicht treibereinstellung?

c ya,
nco2k