Archive for Februar, 2009
Ab und zu findet man doch interessante Sachen auf Youtube, runterladen kann man sich diese ja mit einem der vielen angebotenen Videodownload Tools. Was aber wenn es sich um eine prall gefüllte Playlist handelt? Und man am besten auch noch die Hochauflösenden Videos haben mag?
youtube-dl scheint mir DIE Lösung zu sein. Dank Python sollte es auf allen nennenswerten OS laufen. Getestet habe ich es nur über Nacht hier unter Linux… eine Anleitung für Windows gibt es hier: youtube-dl under Windows XP
Eine Warnung aber noch, es besitzt KEINE Gui! Also Anleitung lesen und das Skript per Hand mit Parametern füttern.
Wenn man anstelle der URL eines Videos die URL einer Playlist angibt, saugt er einem die gesamte Liste. Mit dem Parameter -b bekommt man auch schön noch die hochauflösenden Videos.
Feines Spielzeug :)
Februar 15th, 2009
Am Dienstag fiel mir doch glatt noch ein Kumpel ein, der vielleicht ein defektes Notebook irgendwo herum zu liegen hat… und keine 24 Stunden später hatte ich ihn überzeugt mir diesen zu leihen ;)
1.6 Ghz, 512 MB Ram, 40 GB Festplatte… WLan, Bluetooth, DVD Brenner… was will man eigentlich mehr zum Arbeiten? Ok, das DVD Laufwerk arbeitet nur wenn es willig ist und der eine 256MB Riegel war leider an einer Speicherstelle defekt, danke Memtest, und musste entfernt werden. Aber ansonsten läuft er und ich bin heftigst am Einrichten.
Archlinux mit Openbox, wie auf meinem anderen. Aber diesmal werde ich doch ein wenig mehr Zeit in Conky oder Dzen2 investieren und dem Desktop eine persönlichere Note verpassen.
Wenn sich das gute Notebook auch noch während meines in zwei Wochen beginnenden Praktikums als willig erweist, wäre ich glatt gewillt es Engel als defekt abzukaufen *lach* und ihm ein bisschen mehr Speicher zu spendieren… wäre dann schon fast ein Eee PC ;)
Februar 15th, 2009
Habe das Timerproblem gestern noch irgendwie gelöst bekommen und kann mich nun den Szenen widmen. Hier möchte ich aber mal nicht einfach wild drauf los programmieren und widme der ganzen Sache lieber mal ein paar Bedenkminuten xD
Als erstes habe ich mich mal nach einem niedlichen Karteneditor umgesehen und tiled gefunden. Ist in Java geschrieben und läuft deshalb auch schön unter jedem ernst zu nehmenden Betriebssystem. Was ich auch noch sehr praktisch finde ist das die Karten in XML gespeichert werden und das man innerhalb des Karteneditors seinen Objekten Eigenschaften zuweisen kann.
Letzteres ist zum Beispiel dann praktisch, wenn man z.B. einen Notizzettel einfügt. Diesem könnte man also schon beim Entwerfen der Karte seinen Inhalt verpassen. Oder Teleportfeldern ihren Zielteleporter… Feine Sache :)
Intern werde ich die Szenen in ca. drei 2D Arrays speichern. In dem ersten kommen Bodenfliesen. Warum? Mir ist bei Robot 3 aufgefallen, das es nicht sehr schön aussieht, wenn man eine Mauer im Wald wegätzt, da sich dann dort eine weiße Fliese mitten im Wald befindet. Schöner wäre es, wenn dort meinetwegen brauner Waldboden angezeigt würde. Genau das ermöglicht mir dann mein erstes Array (nenne ich einfach mal Layer 0 xD).
Layer 1 wird alle weiteren nicht-NPC Spielobjekte enthalten. Und in Layer 2 kommen dann Dächer und alles andere unter dem Charlie lang laufen könnte. Befindet sich Charlie meinetwegen in einem Haus, wird einfach Layer 2 nicht mehr gezeichnet und wir haben den selben Effekt wie in Game of Robot mit den Dächern :)
NPCs und alle abgelegten Objekte kommen jeweils in eine Liste. Diese sind dann nicht sooooo lang das es zu Verzögerungen kommt und ich habe trotz allem die Möglichkeit mehrere Objekte auf ein und dem selben Feld zu haben. Denn diese Situation ergibt sich meines Erachtens nach nur, wenn der Spieler Objekte ablegt. Oder ist mir da was entgangen?
Momentan habe ich ja für jeden Objekttyp ein eigenes PNG, verträgt sich aber leider mit tiled nicht so toll. Werde hier also wieder auf ein einziges Bild für ein komplettes Tileset umstellen. Ein, zwei Änderungen an der Objektbasisklasse und auch dieses kleine Problem wäre gelöst.
Ich hoffe mal, das ich dies alles noch innerhalb dieser Woche schaffe, denn dann kann ich mich wieder an der GUI austoben ;)
Februar 8th, 2009
Weil in Löve alles so gut funktioniert hatte, habe ich dessen Timer nachgebaut und vorsorglich alle Float Variablen auf Integer umgestellt. Das brachte einen schönen Geschwindigkeitsschub und meine Animationen klappten auch perfekt. Aber eben wollte ich die flüssigen Objektbewegungen einbauen und alles fing an zu haken. Also alles wieder zurück auf Float umgebaut. Nun sind sie etwas flüssiger, aber er rechnet sich dumm und dämlich, 20 FPS Verlust :(
Es muss doch besser gehen… mal schaun…
Februar 7th, 2009
Die meisten Grundfunktionen sind ohne zu murren in ihren neuen Singleton-Heimen (Screen, Timer, Image) verschwunden. Die Game Klasse nimmt auch langsam Form an :)
Der nächste Schritt ist die Objekt Basisklasse für die Spielelemente. Erst einmal will ich sehen wie es sich in freier Wildbahn verhält, da es sich ja auch um eventuelle Animationen kümmern muss. Ohne Löve muss ich mich ja diesmal selbst darum kümmern *lach*
Was mir aber aufgefallen ist, in der Löve GORC Version hat jede Objektinstanz eine eigene Bildinstanz gehabt… was natürlich nicht unbedingt ressourcenschonend war. Diesmal habe ich aber darauf geachtet das ein Bild nur einmal geladen wird und bei jedem weiteren “Laden” aus dem Cache genommen wird.
Ich komme also voran… und das trotz Erkältung und extrem langsamem Denkprozess xD
Februar 6th, 2009
Vorhin war ich mir ja immer noch nicht sicher. Aber kaum hatte ich auf herc’s Kommentar geantwortet, zeigte sich D (wieder) ziemlich unbeeindruckt von meiner Vorstellung vom Vererben der Variablen und Funktionen einer Elternklasse an ihre Kiddies.
Ich gebe ja zu das ich nicht so recht weiss was ich mit Dingen wie “virtuell” und “protected” anfangen soll. Aber wenn ich z.B.:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| class Image
{
...
void draw(uint x, uint y)
{
...
}
...
}
class Animation : Image
{
...
void draw()
{
draw(1, 1);
}
...
} |
habe, wieso um Gotteswillen der D Kompiler meckern muss, das die Animationsklasse keine draw(uint, uint) Funktion besitzt? Meinem Verständnis nach sollten sie diese doch aus der Image Klasse geerbt haben, oder? Ok, dank Google weiss ich das es so aus sehen muss:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| class Image
{
...
void draw(uint x, uint y)
{
...
}
...
}
class Animation : Image
{
...
alias Image.draw draw;
void draw()
{
draw(1, 1);
}
...
} |
Puh! Langsam glaube ich wirklich, wer mit den OOP Prinzipien nicht im Schlaf umzugehen weiss, sollte von D die Finger lassen :(
Also… nehme ich C++, welches mit meinem Unwissen ein wenig gnädiger umgeht, und versuche es zu lernen ;)
Februar 5th, 2009
Habe mich eben gefragt was das wohl für Kommentare waren, die mir das Askimet Plugin stillschweigend vorenthalten hat. Die Kommentare von herc musste ich eh schon immer von Hand wieder aus dem Spamfilter fischen… da war das Plugin wenigstens so gnädig MICH entscheiden zu lassen, aber die anderen zwei innerhalb der letzten vier Stunden habe ich nicht einmal zu Gesicht bekommen. Und wenn das gar kein Spam war?
Jedenfalls ist Askimet jetzt erst einmal aus und ich werde die wenigen Kommentare lieber von Hand filtern.
Februar 5th, 2009
Hier auf meinem alten Laptop läuft GORC viel viel zu langsam. Das liegt zum größten Teil daran das Löve auf OpenGL setzt. SDL für eine 2D Spieleengine hätte vollkommen ausgereicht. Naja. Aber was nun?
Eigentlich ein ziemlich guter Zeitpunkt um GORC in einer “richtigen” Programmiersprache neu zu schreiben und gleich die SDL Bibliothek zu nutzen. Schließlich brauche ich hier nicht mehr als SDL, SDL_Mixer und SDL_Image. Später fürs Skripting noch Lua, aber bis dahin ist noch Zeit…
In die engere Wahl kommen dabei 4 Sprachen: C, C++, FreeBASIC und Digital Mars D. Letzteres wollte ich schon immer mal ein wenig genauer beschnuppern. Die Bibliotheken meiner Wahl unterstützen alle.
Zu C und C++ mag ich gar nicht allzu viel schreiben. Kann so ziemlich für alles kompiliert werden und ich liebe einfach deren Syntax :)
FreeBASIC ist quasi ein C mit QuickBasic Syntax. Kann aber leider nur für Windows und Linux kompilieren.
D soll wohl “besser” sein als C++. Inwiefern sich das auf ein einfaches Projekt wie GORC auswirkt, keine Ahnung. Das Kompilieren gestaltet sich dank DSSS viel einfacher als bei C/C++. Denn ich habe es noch nie wirklich hinbekommen, das meine Programmchen sich per ./configure && make kompilieren ließen. Ist mir einfach zu aufwendig das ganze *lach*
Hier auch mal ein kleiner Blick in Richtung D:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| import derelict.sdl.sdl;
import tango.io.Console;
void main()
{
try {
DerelictSDL.load();
} catch (Exception e) {
Cout("Could not load the SDL shared library.\n");
return;
}
SDL_Init(SDL_INIT_VIDEO);
SDL_SetVideoMode(640, 348, 24, SDL_SWSURFACE);
SDL_WM_SetCaption("GORC", null);
mainLoop:
while (true) {
SDL_Event event;
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_QUIT:
break mainLoop;
default:
break;
}
}
SDL_Delay(10);
}
Cout("Oki Dokili.\n");
SDL_Quit();
DerelictSDL.unload();
} |
Also? Was nehm ich denn nun?
Februar 3rd, 2009
War im ersten Moment nicht wirklich glücklich darüber, doch den alten Laptop wieder nutzbar zu machen. XP brauchte ich gar nicht erst zu installieren… Ubuntu lief ähnlich langsam und stockend. Bin dann aber zufällig auf die Slitaz Distribution gestoßen. 25 MB ist die Live CD “groß” und brauchte nur knappe 30 Sekunden zum booten (Die Installation auf Festplatte dauerte auch keine 5 Minuten). Erstaunlicher war es dann, das sich alle Anwendungen (außer Firefox und Openoffice) ohne Verzögerungen starten ließen. Und dabei muss man auch nicht auf aktuelle Versionen der ganzen Programme und Bibliotheken verzichten! Hätte sich jetzt auch noch Löve kompilieren lassen, hätte ich bei Slitaz bleiben können. Hätte…
So ist es also doch ein Archlinux mit Openbox, Pypanel und Conky geworden. Nach ein wenig Bastelei bekam ich dann sogar noch die 1440×900 Auflösung meines TFT hin :) Zwar alles einen Tick langsamer als unter Slitaz (Slitaz hatte beim Booten alle Programme in den Speicher geladen, weshalb alles recht schnell reagierte) aber man kann auch auf dieser alten Kiste wieder recht gut arbeiten. Löve ließ sich nach ein paar Änderungen an den Quelltexten dann auch anstandslos Kompilieren.
Negativ fürs Programmieren an GORC ist dann aber leider die Tatsache, das Löve auf OpenGL setzt und ich keine Hardwarebeschleunigung hinbekomme. Deshalb durchgängig 3 bis 6 Frames pro Sekunde *würg* Da muss ich mir also auch wieder was einfallen lassen *lach*
Februar 1st, 2009
