Retro-Contest Part 2

Übersicht

Sonstiges

Smalltalk

Gehe zu Seite Zurück 1, 2, 3 Weiter

	BladeRunner Moderator	Di, Nov 05, 2013 12:38 Antworten mit Zitat
Alles was konstant ist benötigt auch speicher im KonstantenArray, daher ist das ersetzen per define nur sinnvoll um einen Verweis auf einen Slot im Array zu erstellen.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Di, Nov 05, 2013 12:38
Antworten mit Zitat

Alles was konstant ist benötigt auch speicher im KonstantenArray, daher ist das ersetzen per define nur sinnvoll um einen Verweis auf einen Slot im Array zu erstellen.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Nova	So, Nov 17, 2013 6:13 Antworten mit Zitat
Scheint, als gäbe es keine Abgabe. Finde ich weder überraschend, noch verwunderlich.
AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

Nova

So, Nov 17, 2013 6:13
Antworten mit Zitat

Scheint, als gäbe es keine Abgabe. Finde ich weder überraschend, noch verwunderlich.

AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

	BladeRunner Moderator	So, Nov 17, 2013 10:58 Antworten mit Zitat
Zitat: Finde ich weder überraschend, noch verwunderlich. Fühl dich frei dass ausführlicher zu begründen. Schade dass niemand mitgemacht hat.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

So, Nov 17, 2013 10:58
Antworten mit Zitat

Zitat:

Finde ich weder überraschend, noch verwunderlich.

Fühl dich frei dass ausführlicher zu begründen.

Schade dass niemand mitgemacht hat.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	DAK	So, Nov 17, 2013 15:43 Antworten mit Zitat
Sorry, wollte ich eh, aber es ist Mitte des Semesters. Ich komm vor lauter Uni kaum zum Arbeiten, geschweige denn noch hobbymaßig was zu programmieren...
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

So, Nov 17, 2013 15:43
Antworten mit Zitat

Sorry, wollte ich eh, aber es ist Mitte des Semesters. Ich komm vor lauter Uni kaum zum Arbeiten, geschweige denn noch hobbymaßig was zu programmieren...

Gewinner der 6. und der 68. BlitzCodeCompo

	feider ehemals "Decelion"	So, Nov 17, 2013 17:31 Antworten mit Zitat
Dito. Ich habe aktuell zwei Projekte, für die ich arbeiten muss und dazu noch den ganzen Unikram, der extrem viel Zeit einnimmt. Thematisch war der Contest sehr sehr sehr interessant und trifft genau meinen Geschmack - habe auch die Grundlage meines Spieles mit C und SDL vorbereitet (die Zeichenfunktion für den Bildschirm mit 10003 Bit etc..), kam jedoch nicht dazu, das Ganze fertig zu machen. Edit: Es waren natürlich 10003 Bit, nicht Byte

feider

ehemals "Decelion"

So, Nov 17, 2013 17:31
Antworten mit Zitat

Dito. Ich habe aktuell zwei Projekte, für die ich arbeiten muss und dazu noch den ganzen Unikram, der extrem viel Zeit einnimmt.
Thematisch war der Contest sehr sehr sehr interessant und trifft genau meinen Geschmack - habe auch die Grundlage meines Spieles mit C und SDL vorbereitet (die Zeichenfunktion für den Bildschirm mit 1000*3 Bit etc..), kam jedoch nicht dazu, das Ganze fertig zu machen.

Edit: Es waren natürlich 1000*3 Bit, nicht Byte Wink

	Nova	Mi, Nov 20, 2013 1:20 Antworten mit Zitat
Persönlich fand ich die Regel zu kompliziert und unnötig komplex. Meiner Ansicht nach war die Sache mit dem "Farbram" auch nicht sinnvoll. Ich habe weder verstanden, wie man den vernünftig nutzen soll, noch wie die Ausgabe mit dem "Zeichenarray" bitte funktionieren soll. Außerdem verwirrt mich der Satz zum Sprite: "(also -8 -- 320 / -8 -- 200)" - keine Ahnung, was das bedeuten soll. Ansonsten wären da halt noch Fragen, die genauer auf einige Sachen eingehen: Sind Befehle erlaubt, die Beispielsweise den "Beep" mittels SoundPitch manipulieren und somit Melodien erzeugen? Durch die vielen (meiner Ansicht nach) Ungereimtheiten hat der Contest mich ziemlich abgeschreckt. Dies ist meine Meinung dazu. Da ich allerdings vermute, dass andere diese Probleme nicht haben und daher vielleicht doch etwas abgeben, habe ich dazu nichts gesagt. Um alle "meine" Probleme mit dem Contest zu beheben, müsste man ihn eh so stark abändern, dann es gleich ein ganz neuer Contest wäre. Daher habe ich nichts dazu gesagt.
AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

Nova

Mi, Nov 20, 2013 1:20
Antworten mit Zitat

Persönlich fand ich die Regel zu kompliziert und unnötig komplex. Meiner Ansicht nach war die Sache mit dem "Farbram" auch nicht sinnvoll. Ich habe weder verstanden, wie man den vernünftig nutzen soll, noch wie die Ausgabe mit dem "Zeichenarray" bitte funktionieren soll. Außerdem verwirrt mich der Satz zum Sprite: "(also -8 -- 320 / -8 -- 200)" - keine Ahnung, was das bedeuten soll.
Ansonsten wären da halt noch Fragen, die genauer auf einige Sachen eingehen: Sind Befehle erlaubt, die Beispielsweise den "Beep" mittels SoundPitch manipulieren und somit Melodien erzeugen?

Durch die vielen (meiner Ansicht nach) Ungereimtheiten hat der Contest mich ziemlich abgeschreckt. Dies ist meine Meinung dazu. Da ich allerdings vermute, dass andere diese Probleme nicht haben und daher vielleicht doch etwas abgeben, habe ich dazu nichts gesagt. Um alle "meine" Probleme mit dem Contest zu beheben, müsste man ihn eh so stark abändern, dann es gleich ein ganz neuer Contest wäre. Daher habe ich nichts dazu gesagt. Wink

AMD Athlon II 4x3,1GHz, 8GB Ram DDR3, ATI Radeon HD 6870, Win 7 64bit

	feider ehemals "Decelion"	Mi, Nov 20, 2013 9:30 Antworten mit Zitat
Möchte hierzu noch einwerfen, dass ich mit den Regeln keine Probleme hatte. Zudem bestand ja auch immer die Möglichkeit der Nachfrage. "Unnötig Komplex" - bei dem Wettbewerb ging es darum, unter Einschränkungen etwas zu tun. Insofern passt das doch.

feider

ehemals "Decelion"

Mi, Nov 20, 2013 9:30
Antworten mit Zitat

Möchte hierzu noch einwerfen, dass ich mit den Regeln keine Probleme hatte.
Zudem bestand ja auch immer die Möglichkeit der Nachfrage.

"Unnötig Komplex" - bei dem Wettbewerb ging es darum, unter Einschränkungen etwas zu tun. Insofern passt das doch.

	BladeRunner Moderator	Mi, Nov 20, 2013 10:37 Antworten mit Zitat
Ich hätte gerne für jedwede Nachfrage zur Verfügung gestanden. Das Modell mit dem Farbram ist echten 8-Bit Computern nachempfunden, wie zB dem C64. RAM war zu der Zeit sehr teuer und die Prozessoren hatten idR auch nur einen 16-Bit Datenbus, weshalb lediglich 64KB adressierbar waren. Daher haben sich die Entwickler Möglichkeiten ausgedacht um die Grafikfähigkeiten trotz der begrenzten Hardware möglichst gut zu nutzen. Der C64 hat für jede seiner 1000 (4025) Zeichen auf dem Bildschirm ein Halbbyte an Farbram, mit welchem die einzuzeichnende Farbe festgelegt wird. Er konnte also 2^4 -> 16 Farben darstellen. Diese waren in einer festen Palette hinterlegt. Einen normalen Text in Farbe auf dem Bildschirm darzustellen 'kostete' also 1000 Byte für die Zeichen, 1000 Halbbyte für die Farbe und dann noch ein Byte für die Hintergrundfarbe des Schirms. Das war eine sehr effiziente Methode der Darstellung. Zudem wurde das Farbram auch für Grafikmodi als eine Art Tabelle genutzt, welche Farbe pro 88 Pixel (was einem Zeichen Größe entsprach) im Vordergrund zu sehen ist. Zusätzlich wurde dann im Normalen RAM noch weitere 1000Byte RAM genutzt, die noch zwei andere Farben pro Block definierten. Damit konnte der C64 pro "Zeichen" bis zu 4 Farben nutzen: Hintergrund, FarbRAM, HiNibble des externen Farbspeichers und dessen LONibble (Ein Nibble ist ein Halbbyte). Zur damaligen Zeit war diese Grafikfähigkeit revolutionär. Eine Grafik kostete dann 8KB RAM+ 1KB externes Farbram,das andere KB war ja intern und wurde vom VideoChip in den Adressraum des C64 gemappt. Hätte man, wie bei heutigen Systemen üblich, einfach Bitplanes genommen, wäre die Grafik ungleich größer gewesen, wenn auch mit weniger Einschränkungen bei der Darstellung. Eine Grafik mit 4 Bitplanes, also 16 Farben möglich, und das für jeden einzelnen Pixel, hätte gleich mal 32KB der 64KB RAM verbraten. Und genau darum ging es mir in diesem Contest: Die Beschränkungen sollten ein Anreiz sein zu zeigen was man alles aus wenig rausholen kann.

BladeRunner

Moderator

Mi, Nov 20, 2013 10:37
Antworten mit Zitat

Ich hätte gerne für jedwede Nachfrage zur Verfügung gestanden.
Das Modell mit dem Farbram ist echten 8-Bit Computern nachempfunden, wie zB dem C64. RAM war zu der Zeit sehr teuer und die Prozessoren hatten idR auch nur einen 16-Bit Datenbus, weshalb lediglich 64KB adressierbar waren. Daher haben sich die Entwickler Möglichkeiten ausgedacht um die Grafikfähigkeiten trotz der begrenzten Hardware möglichst gut zu nutzen.
Der C64 hat für jede seiner 1000 (40*25) Zeichen auf dem Bildschirm ein Halbbyte an Farbram, mit welchem die einzuzeichnende Farbe festgelegt wird. Er konnte also 2^4 -> 16 Farben darstellen. Diese waren in einer festen Palette hinterlegt.
Einen normalen Text in Farbe auf dem Bildschirm darzustellen 'kostete' also 1000 Byte für die Zeichen, 1000 Halbbyte für die Farbe und dann noch ein Byte für die Hintergrundfarbe des Schirms.
Das war eine sehr effiziente Methode der Darstellung.
Zudem wurde das Farbram auch für Grafikmodi als eine Art Tabelle genutzt, welche Farbe pro 8*8 Pixel (was einem Zeichen Größe entsprach) im Vordergrund zu sehen ist. Zusätzlich wurde dann im Normalen RAM noch weitere 1000Byte RAM genutzt, die noch zwei andere Farben pro Block definierten. Damit konnte der C64 pro "Zeichen" bis zu 4 Farben nutzen: Hintergrund, FarbRAM, HiNibble des externen Farbspeichers und dessen LONibble (Ein Nibble ist ein Halbbyte).
Zur damaligen Zeit war diese Grafikfähigkeit revolutionär.
Eine Grafik kostete dann 8KB RAM+ 1KB externes Farbram,das andere KB war ja intern und wurde vom VideoChip in den Adressraum des C64 gemappt.
Hätte man, wie bei heutigen Systemen üblich, einfach Bitplanes genommen, wäre die Grafik ungleich größer gewesen, wenn auch mit weniger Einschränkungen bei der Darstellung. Eine Grafik mit 4 Bitplanes, also 16 Farben möglich, und das für jeden einzelnen Pixel, hätte gleich mal 32KB der 64KB RAM verbraten.

Und genau darum ging es mir in diesem Contest: Die Beschränkungen sollten ein Anreiz sein zu zeigen was man alles aus wenig rausholen kann.

	DAK	Mi, Nov 20, 2013 10:51 Antworten mit Zitat
Ich hab die Regeln jetzt nicht so schlimm kompliziert gefunden. Waren meiner Meinung nach deutlich besser als beim letzten Retro-Contest, vor allem deutlich weniger unscharf. Ich hab auch schon angefangen gehabt, was zu programmieren, aber dann sind mir doch die 5 Projekte, die ich dieses Semester im Rahmen von Gruppenarbeiten machen muss, sowie die zwei Projekte, die ich in der Arbeit machen muss, dazwischen gekommen. Bin hald nicht mehr in der Schule (so wie sehr viele andere hier, denke ich), und wenn man aus Pflicht programmieren muss (Uni/Arbeit), dann wird es deutlich weniger interessant, in der Freizeit noch was anderes zu programmieren
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Nov 20, 2013 10:51
Antworten mit Zitat

Ich hab die Regeln jetzt nicht so schlimm kompliziert gefunden. Waren meiner Meinung nach deutlich besser als beim letzten Retro-Contest, vor allem deutlich weniger unscharf.

Ich hab auch schon angefangen gehabt, was zu programmieren, aber dann sind mir doch die 5 Projekte, die ich dieses Semester im Rahmen von Gruppenarbeiten machen muss, sowie die zwei Projekte, die ich in der Arbeit machen muss, dazwischen gekommen.

Bin hald nicht mehr in der Schule (so wie sehr viele andere hier, denke ich), und wenn man aus Pflicht programmieren muss (Uni/Arbeit), dann wird es deutlich weniger interessant, in der Freizeit noch was anderes zu programmieren Wink

Gewinner der 6. und der 68. BlitzCodeCompo

	BladeRunner Moderator	Mi, Nov 20, 2013 10:59 Antworten mit Zitat
Ich muss allerdings auch zugeben dass ich verstehe wenn die Regeln als recht komplex empfunden werden. Ich selbst sammle die alten Kisten und kennes sie von frühester Kindheit an. Ic kann nicht erwarten dass das bei jedem hier so ist. Sollte ich ein Revival des Contest durchführen werde ich mit gutem Beispiel voran gehen und einen lauffähigen Beispielcode mitgeben.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Mi, Nov 20, 2013 10:59
Antworten mit Zitat

Ich muss allerdings auch zugeben dass ich verstehe wenn die Regeln als recht komplex empfunden werden. Ich selbst sammle die alten Kisten und kennes sie von frühester Kindheit an. Ic kann nicht erwarten dass das bei jedem hier so ist.
Sollte ich ein Revival des Contest durchführen werde ich mit gutem Beispiel voran gehen und einen lauffähigen Beispielcode mitgeben.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	DAK	Mi, Nov 20, 2013 19:53 Antworten mit Zitat
Eventuell wäre eine Art kleines Framework mit den Grundfunktionen in den erlaubten Sprachen toll. Da hast du dann Funktionen wie: -getRAMVal(Adresse) -setRAMVal(Adresse,Wert) -initConstVal(Adresse,Wert) (Darf nur am Anfang vor dem Lesen verwendet werden) -getConstVal(Adresse) -setPixel(x,y,Wert) -setPixelColor(x,y,Wert) Als Regel heißt es dann: Lokale und Globale Variablen sowie alle Datenstrukturen sind verboten. Bildausgabe darf nur über die gegebenen Funktionen erfolgen. Zahlen (also konstante Werte) dürfen nur für die Adressen verwendet werden. Das in ein paar Sprachen implementieren sollte nicht so schwer werden, bzw. wenn wer eine andere Sprache verwenden will, muss er diese Funktionen mit genau deren Regeln in seiner Sprache implementieren. Das sollte dann von den Regeln her in etwa dem entsprechen, was du für den RetroContest haben wolltest, ist aber deutlich einfacher zu befolgen, vor allem, wenn du eben das Framework schon hergibst.
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Mi, Nov 20, 2013 19:53
Antworten mit Zitat

Eventuell wäre eine Art kleines Framework mit den Grundfunktionen in den erlaubten Sprachen toll.

Da hast du dann Funktionen wie:
-getRAMVal(Adresse)
-setRAMVal(Adresse,Wert)
-initConstVal(Adresse,Wert) (Darf nur am Anfang vor dem Lesen verwendet werden)
-getConstVal(Adresse)
-setPixel(x,y,Wert)
-setPixelColor(x,y,Wert)

Als Regel heißt es dann: Lokale und Globale Variablen sowie alle Datenstrukturen sind verboten. Bildausgabe darf nur über die gegebenen Funktionen erfolgen.
Zahlen (also konstante Werte) dürfen nur für die Adressen verwendet werden.

Das in ein paar Sprachen implementieren sollte nicht so schwer werden, bzw. wenn wer eine andere Sprache verwenden will, muss er diese Funktionen mit genau deren Regeln in seiner Sprache implementieren.

Das sollte dann von den Regeln her in etwa dem entsprechen, was du für den RetroContest haben wolltest, ist aber deutlich einfacher zu befolgen, vor allem, wenn du eben das Framework schon hergibst.

Gewinner der 6. und der 68. BlitzCodeCompo

	Thunder	Do, Nov 21, 2013 16:54 Antworten mit Zitat
Ok, ich hätte sowieso keine Zeit gefunden, teilzunehmen, aber was mir negativ aufgefallen ist: - Ich fand besonders die Konstantenregelung seeehr unverständlich und irgendwie unnötig. Wenn ich jetzt eine Formel y = 2 * x habe, ist die 2 ja streng genommen auch eine Konstante, oder? - Außerdem hätte ich wahrscheinlich versucht mit Assembler teilzunehmen (der Wettbewerb war ja für alle Sprachen offen, richtig?). Welche Sprache wäre wohl besser für einen Retro-Contest geeignet? Aber es hätte einige Fragen aufgeworfen (Register sind auch Variablen? - dann hätten andere Sprachen einen Vorteil, Prüfaufwand weil schlecht überschaubar ...) Ich würde gerne an so einem Wettbewerb teilnehmen, aber ohne ein fixes Framework (macht alles nur langsamer). Wie auch immer. Einfach keine Zeit gehabt. :/

Thunder

Do, Nov 21, 2013 16:54
Antworten mit Zitat

Ok, ich hätte sowieso keine Zeit gefunden, teilzunehmen, aber was mir negativ aufgefallen ist:

- Ich fand besonders die Konstantenregelung seeehr unverständlich und irgendwie unnötig. Wenn ich jetzt eine Formel y = 2 * x habe, ist die 2 ja streng genommen auch eine Konstante, oder?

- Außerdem hätte ich wahrscheinlich versucht mit Assembler teilzunehmen (der Wettbewerb war ja für alle Sprachen offen, richtig?). Welche Sprache wäre wohl besser für einen Retro-Contest geeignet? Very Happy

Aber es hätte einige Fragen aufgeworfen (Register sind auch Variablen? - dann hätten andere Sprachen einen Vorteil, Prüfaufwand weil schlecht überschaubar ...)

Ich würde gerne an so einem Wettbewerb teilnehmen, aber ohne ein fixes Framework (macht alles nur langsamer). Wie auch immer. Einfach keine Zeit gehabt. :/

	feider ehemals "Decelion"	Fr, Nov 22, 2013 3:46 Antworten mit Zitat
2*x wäre eigentlich keine konstante, da du das auch durch einen shift left erreichen kannst

feider

ehemals "Decelion"

Fr, Nov 22, 2013 3:46
Antworten mit Zitat

2*x wäre eigentlich keine konstante, da du das auch durch einen shift left erreichen kannst Wink

	DAK	Fr, Nov 22, 2013 10:14 Antworten mit Zitat
Wie gesagt, nicht unbedingt klare Konstantenregelung
Gewinner der 6. und der 68. BlitzCodeCompo

DAK

Fr, Nov 22, 2013 10:14
Antworten mit Zitat

Wie gesagt, nicht unbedingt klare Konstantenregelung Wink

Gewinner der 6. und der 68. BlitzCodeCompo

	tft	So, Nov 24, 2013 10:27 Antworten mit Zitat
Hi, also ich habe bis heute versucht etwas zu stande zu bringen. Aber leider hat der Technik Check jedesmal eine Verletzung der Regeln preisgegeben. Die Vorgaben sind schon sehr eng. Aber nicht unmöglich. Für mich als Hobby Coder zu wenig Zeit. Gruss TFT PS : War eine sehr gelungene Herrausvorderung.
TFT https://www.sourcemagic.ch Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!!

tft

So, Nov 24, 2013 10:27
Antworten mit Zitat

Hi,

also ich habe bis heute versucht etwas zu stande zu bringen. Aber leider hat der Technik Check jedesmal eine Verletzung der Regeln preisgegeben. Die Vorgaben sind schon sehr eng. Aber nicht unmöglich. Für mich als Hobby Coder zu wenig Zeit.

Gruss TFT

PS : War eine sehr gelungene Herrausvorderung.

TFT
https://www.sourcemagic.ch
Monkey,HTML5,CSS3,W 10 64 Bit, 32 GB Ram, GTX Titan, W8 ist Müll !!!!!!

	Jan_ Ehemaliger Admin	Mo, Nov 25, 2013 8:38 Antworten mit Zitat
Bei mir war es auch eindeutig die Zeit, im Winter ist immer sehr viel auf Arbeit zu machen.
between angels and insects

Jan_

Ehemaliger Admin

Mo, Nov 25, 2013 8:38
Antworten mit Zitat

Bei mir war es auch eindeutig die Zeit, im Winter ist immer sehr viel auf Arbeit zu machen.

between angels and insects

	Silver_Knee	Do, Apr 16, 2015 12:17 Antworten mit Zitat
Hey, ich bin gerade beim Stöbern hierauf gestoßen. Denke man hat sich darmals nur etwas übernommen. Ich habe einfch mal das einfachste Spiel, was ich mir Vorstellen kann auf der "Hardware" in BlitzMax implementiert: Pong mit 2 Spielern. Hat 1,5 Stunden gedauert und ich habe mir eine "Dehnung" der Regeln erlaubt: Das Sprite habe ich jetzt nicht selbst mit 8x8 Pixeln gefüllt, sondern die Hardware zeigt dort ein Oval x,y,8,8 an. Dass der Ball mit der Zeit schneller wird habe ich auskommentiert, weil das Spielfeld so klein ist. Die rechte Hälfte des Spielfelds ist etwas gekürzt, weil ich zu faul war 2 Byte aus VAR zu einem Short für das Ball-x zu nehmen. Damit kann das maximal 255 werden. Das mit dem unsigned Byte war übrigens garnicht so das Problem. Bei ballx=ballx+ballxspeed, dachte ich, hier müsste ich mir was einfallen lassen für die negativen speed-Werte, funktioniert allerdings wunderbar, wenn man sich auf den Übelauf verlässt ((3-1)+256) Mod 256=2 entspricht ((3+255)+256) Mod 256=2. Das einzige Mal, wo ich negative Zahlen brauchte, war bei der Kollisionsprüfung. Da war > und < nunmal nur für negative Zahlen auch richtig. Daher sind da in den Zeilen jeder VAR[...] in ein Int gecasted. Ich hoffe, das ist Regelkonform. Außerdem habe ich die Arrays mit OUTPUT[x,y] addressiert. Kann man umschreiben mit OUTPUT[X(CONST[0]+CONST[254]) + Y]. Der Code wird davon aber noch schlimmer, als er jetzt schon ist Die 4 Konstanten für die Tasten würden noch in das CONSTS-Array passen. Habe sie im Init auch angedeutet, hatte jetzt nicht so viel Lust, die noch in einzelne Bytes zu schneiden. Hier ist der Code: BlitzMax:* [AUSKLAPPEN] [EINKLAPPEN] SuperStrict Framework brl.glmax2d Import brl.polledinput Global VARS:Byte[32] Global CONSTS:Byte[256] Global OUTPUT:Byte[40 , 25] Global COLOR:Byte[40 , 25] Global PALETTE:HW_COLOR[8] Global SPRITE:HW_SPRITE=New HW_SPRITE '__INIT__ HW_INIT PALETTE[0] = HW_COLOR.GET(255 , 255 , 255) 'gfx CONSTS[0] = 39 CONSTS[1] = 24 CONSTS[2] = 8 CONSTS[3] = (256-8)/8 CONSTS[10] = Asc("\|") 'KEY_-Constants 'KEY_W 'KEY_S 'KEY_UP 'KEY_DOWN 'simple numbers CONSTS[253]=0 CONSTS[254]=1 CONSTS[255]=255 'ball VARS[0] = 208 'x VARS[1] = 128 'y VARS[2] = 1 'xs VARS[3] = -1 'ys 'p1 VARS[10] = 12 'y VARS[11] = 0 'points 'p2 VARS[20] = 12 VARS[21] = 0 'points 'vars 30,31 = tmp 'Border For VARS[31] = CONSTS[3] + 1 To CONSTS[0] For VARS[30] = CONSTS[253] To CONSTS[1] OUTPUT[VARS[31] , VARS[30]] = Asc("X") Next Next '__MAINLOOP__ Repeat 'input If KeyDown(KEY_W) And VARS[10] > CONSTS[254] VARS[10]:-CONSTS[254] EndIf If KeyDown(KEY_S) And VARS[10] < CONSTS[1]-CONSTS[254] VARS[10]:+CONSTS[254] EndIf If KeyDown(KEY_UP) And VARS[20] > CONSTS[254] VARS[20]:-CONSTS[254] EndIf If KeyDown(KEY_DOWN) And VARS[20] < CONSTS[1]-CONSTS[254] VARS[20]:+CONSTS[254] EndIf 'processing VARS[0]:+VARS[2] VARS[1]:+VARS[3] If VARS[1] < CONSTS[2] VARS[3] = -VARS[3]' + CONSTS[254] EndIf If VARS[1] > (CONSTS[1] - CONSTS[254]) * CONSTS[2] VARS[3] = -VARS[3]' - CONSTS[254] EndIf If VARS[0] > CONSTS[255] - CONSTS[2] If Int(VARS[20])Int(CONSTS[2]) - Int(CONSTS[2]Shl CONSTS[254]) < VARS[1] + CONSTS[2] Shr CONSTS[254] And Int(VARS[20])Int(CONSTS[2]) + Int(CONSTS[2]Shl CONSTS[254]) > VARS[1] + CONSTS[2] Shr CONSTS[254] VARS[2] = - VARS[2] Else VARS[11]:+ 1 VARS[0] = 208 'x VARS[1] = 128 'y EndIf EndIf If VARS[0] < CONSTS[2] If Int(VARS[10])Int(CONSTS[2]) - Int(CONSTS[2]Shl CONSTS[254]) < VARS[1] + CONSTS[2] Shr CONSTS[254] And Int(VARS[10])Int(CONSTS[2]) + Int(CONSTS[2]Shl CONSTS[254]) > VARS[1] + CONSTS[2] Shr CONSTS[254] VARS[2] = - VARS[2] Else VARS[21]:+ 1 VARS[0] = 208 'x VARS[1] = 128 'y EndIf EndIf 'output 'p1 For VARS[31] = CONSTS[253] To CONSTS[1] OUTPUT[CONSTS[254] , VARS[31]] = 0 Next OUTPUT[CONSTS[254] , VARS[10]-1] = CONSTS[10] OUTPUT[CONSTS[254] , VARS[10]] = CONSTS[10] OUTPUT[CONSTS[254] , VARS[10]+1] = CONSTS[10] 'p2 For VARS[31] = CONSTS[253] To CONSTS[1] OUTPUT[CONSTS[3] , VARS[31]] = 0 Next OUTPUT[CONSTS[3] , VARS[20]-1] = CONSTS[10] OUTPUT[CONSTS[3] , VARS[20]] = CONSTS[10] OUTPUT[CONSTS[3] , VARS[20]+1] = CONSTS[10] 'points OUTPUT[CONSTS[0] Shr CONSTS[254] - CONSTS[254] , CONSTS[253]] = Asc(VARS[11]) OUTPUT[CONSTS[0] Shr CONSTS[254] + CONSTS[254] , CONSTS[253]] = Asc(VARS[21]) SPRITE.X = VARS[0] SPRITE.Y = VARS[1] HW_OUTPUT() Until AppTerminate() End '__HARDWARE__ Function HW_INIT() SetGraphicsDriver GLMax2DDriver() Graphics 640 , 400 , 0 End Function Function HW_OUTPUT() For Local x:Int = 0 Until 40 For Local y:Int = 0 Until 25 SetColor PALETTE[COLOR[x , y]].red , PALETTE[COLOR[x , y]].green , PALETTE[COLOR[x , y]].blue DrawText Chr(OUTPUT[x,y]),x16+8-TextWidth(Chr(OUTPUT[x,y]))/2,y16+8-TextWidth(Chr(OUTPUT[x,y]))/2 Next Next DrawOval SPRITE.x16/8,SPRITE.y16/8,16,16 Flip Cls End Function Type HW_COLOR Field red:Byte , green:Byte , blue:Byte Function GET:HW_COLOR(red:Byte , green:Byte , blue:Byte) Local this:HW_COLOR= New HW_COLOR this.red = red this.green = green this.blue = blue Return this End Function End Type Type HW_SPRITE Field x:Byte , y:Byte End Type

Silver_Knee

Do, Apr 16, 2015 12:17
Antworten mit Zitat

Hey, ich bin gerade beim Stöbern hierauf gestoßen. Denke man hat sich darmals nur etwas übernommen. Ich habe einfch mal das einfachste Spiel, was ich mir Vorstellen kann auf der "Hardware" in BlitzMax implementiert: Pong mit 2 Spielern. Hat 1,5 Stunden gedauert und ich habe mir eine "Dehnung" der Regeln erlaubt: Das Sprite habe ich jetzt nicht selbst mit 8x8 Pixeln gefüllt, sondern die Hardware zeigt dort ein Oval x,y,8,8 an.

Dass der Ball mit der Zeit schneller wird habe ich auskommentiert, weil das Spielfeld so klein ist. Die rechte Hälfte des Spielfelds ist etwas gekürzt, weil ich zu faul war 2 Byte aus VAR zu einem Short für das Ball-x zu nehmen. Damit kann das maximal 255 werden. Das mit dem unsigned Byte war übrigens garnicht so das Problem. Bei ballx=ballx+ballxspeed, dachte ich, hier müsste ich mir was einfallen lassen für die negativen speed-Werte, funktioniert allerdings wunderbar, wenn man sich auf den Übelauf verlässt ((3-1)+256) Mod 256=2 entspricht ((3+255)+256) Mod 256=2. Das einzige Mal, wo ich negative Zahlen brauchte, war bei der Kollisionsprüfung. Da war > und < nunmal nur für negative Zahlen auch richtig. Daher sind da in den Zeilen jeder VAR[...] in ein Int gecasted. Ich hoffe, das ist Regelkonform. Außerdem habe ich die Arrays mit OUTPUT[x,y] addressiert. Kann man umschreiben mit OUTPUT[X*(CONST[0]+CONST[254]) + Y]. Der Code wird davon aber noch schlimmer, als er jetzt schon ist Very Happy

Die 4 Konstanten für die Tasten würden noch in das CONSTS-Array passen. Habe sie im Init auch angedeutet, hatte jetzt nicht so viel Lust, die noch in einzelne Bytes zu schneiden.

Hier ist der Code:

BlitzMax: [AUSKLAPPEN]

SuperStrict
Framework brl.glmax2d
Import brl.polledinput

Global VARS:Byte[32]
Global CONSTS:Byte[256]
Global OUTPUT:Byte[40 , 25]
Global COLOR:Byte[40 , 25]
Global PALETTE:HW_COLOR[8]
Global SPRITE:HW_SPRITE=New HW_SPRITE

'__INIT__
HW_INIT
PALETTE[0] = HW_COLOR.GET(255 , 255 , 255)

'gfx
CONSTS[0] = 39 
CONSTS[1] = 24 
CONSTS[2] = 8
CONSTS[3] = (256-8)/8

CONSTS[10] = Asc("|")

'KEY_-Constants
'KEY_W
'KEY_S
'KEY_UP
'KEY_DOWN

'simple numbers
CONSTS[253]=0
CONSTS[254]=1
CONSTS[255]=255

'ball
VARS[0] = 20*8 'x
VARS[1] = 12*8 'y

VARS[2] = 1 'xs
VARS[3] = -1 'ys

'p1
VARS[10] = 12 'y
VARS[11] = 0 'points

'p2
VARS[20] = 12
VARS[21] = 0 'points

'vars 30,31 = tmp

'Border
For VARS[31] = CONSTS[3] + 1 To CONSTS[0]
	For VARS[30] = CONSTS[253] To CONSTS[1]
		OUTPUT[VARS[31] , VARS[30]] = Asc("X")
	Next
Next

'__MAINLOOP__
Repeat
	'input
	If KeyDown(KEY_W) And VARS[10] > CONSTS[254]
		VARS[10]:-CONSTS[254]
	EndIf	
	
	If KeyDown(KEY_S) And VARS[10] < CONSTS[1]-CONSTS[254]
		VARS[10]:+CONSTS[254]
	EndIf	

	If KeyDown(KEY_UP) And VARS[20] > CONSTS[254]
		VARS[20]:-CONSTS[254]
	EndIf	
	
	If KeyDown(KEY_DOWN) And VARS[20] < CONSTS[1]-CONSTS[254]
		VARS[20]:+CONSTS[254]
	EndIf	
	
	'processing
	VARS[0]:+VARS[2]
	VARS[1]:+VARS[3]
	
	If VARS[1] < CONSTS[2]
		VARS[3] = -VARS[3]' + CONSTS[254]
	EndIf

	If VARS[1] > (CONSTS[1] - CONSTS[254]) * CONSTS[2]
		VARS[3] = -VARS[3]' - CONSTS[254]
	EndIf
	
	If VARS[0] > CONSTS[255] - CONSTS[2]
		If Int(VARS[20])*Int(CONSTS[2]) - Int(CONSTS[2]Shl CONSTS[254]) < VARS[1] + CONSTS[2] Shr CONSTS[254] And Int(VARS[20])*Int(CONSTS[2]) + Int(CONSTS[2]Shl CONSTS[254]) > VARS[1] + CONSTS[2] Shr CONSTS[254] 
			VARS[2] = - VARS[2]
		Else
			VARS[11]:+ 1
			VARS[0] = 20*8 'x
			VARS[1] = 12*8 'y
		EndIf 
	EndIf

	If VARS[0] < CONSTS[2]
		If Int(VARS[10])*Int(CONSTS[2]) - Int(CONSTS[2]Shl CONSTS[254]) < VARS[1] + CONSTS[2] Shr CONSTS[254] And Int(VARS[10])*Int(CONSTS[2]) + Int(CONSTS[2]Shl CONSTS[254]) > VARS[1] + CONSTS[2] Shr CONSTS[254] 
			VARS[2] = - VARS[2]	
		Else
			VARS[21]:+ 1
			VARS[0] = 20*8 'x
			VARS[1] = 12*8 'y
		EndIf 
	EndIf
	
	'output
	'p1
	For VARS[31] = CONSTS[253] To CONSTS[1]
		OUTPUT[CONSTS[254] , VARS[31]] = 0
	Next
	
	OUTPUT[CONSTS[254] , VARS[10]-1] = CONSTS[10]
	OUTPUT[CONSTS[254] , VARS[10]] = CONSTS[10]
	OUTPUT[CONSTS[254] , VARS[10]+1] = CONSTS[10]
	
	'p2
	For VARS[31] = CONSTS[253] To CONSTS[1]
		OUTPUT[CONSTS[3] , VARS[31]] = 0
	Next
	
	OUTPUT[CONSTS[3] , VARS[20]-1] = CONSTS[10]
	OUTPUT[CONSTS[3] , VARS[20]] = CONSTS[10]
	OUTPUT[CONSTS[3] , VARS[20]+1] = CONSTS[10]

	'points
	OUTPUT[CONSTS[0] Shr CONSTS[254] - CONSTS[254] , CONSTS[253]] = Asc(VARS[11])
	OUTPUT[CONSTS[0] Shr CONSTS[254] + CONSTS[254] , CONSTS[253]] = Asc(VARS[21])

	SPRITE.X = VARS[0]
	SPRITE.Y = VARS[1]
	
	HW_OUTPUT()
Until AppTerminate()
End


'__HARDWARE__
Function HW_INIT()
	SetGraphicsDriver GLMax2DDriver()
	Graphics 640 , 400 , 0
End Function


Function HW_OUTPUT()
	For Local x:Int = 0 Until 40
		For Local y:Int = 0 Until 25
			SetColor PALETTE[COLOR[x , y]].red , PALETTE[COLOR[x , y]].green , PALETTE[COLOR[x , y]].blue
			DrawText Chr(OUTPUT[x,y]),x*16+8-TextWidth(Chr(OUTPUT[x,y]))/2,y*16+8-TextWidth(Chr(OUTPUT[x,y]))/2
		Next 
	Next
	
	DrawOval SPRITE.x*16/8,SPRITE.y*16/8,16,16
	
	Flip
	Cls
End Function

Type HW_COLOR
	Field red:Byte , green:Byte , blue:Byte
	Function GET:HW_COLOR(red:Byte , green:Byte , blue:Byte)
		Local this:HW_COLOR= New HW_COLOR
		this.red = red
		this.green = green
		this.blue = blue
		Return this
	End Function
End Type

Type HW_SPRITE
	Field x:Byte , y:Byte
End Type

	Sirrus	Do, Nov 05, 2015 8:18 Antworten mit Zitat
Das ist zwar ein Thema, das schon 2 Jahre alt ist, aber nachdem niemand BladeRunner widersprochen hat, wollte ich die teilweise falsche Darstellung der C64-Grafik nicht so stehen lassen. Ich habe seit 1982 sehr viel am C64 programmiert und kenne ihn in und auswendig. BladeRunner hat Folgendes geschrieben: Ich hätte gerne für jedwede Nachfrage zur Verfügung gestanden. Das Modell mit dem Farbram ist echten 8-Bit Computern nachempfunden, wie zB dem C64. RAM war zu der Zeit sehr teuer und die Prozessoren hatten idR auch nur einen 16-Bit Datenbus, weshalb lediglich 64KB adressierbar waren. Daher haben sich die Entwickler Möglichkeiten ausgedacht um die Grafikfähigkeiten trotz der begrenzten Hardware möglichst gut zu nutzen. Es ist zunächst einmal richtig, dass der C64 nur 64kB adressieren konnte, er hatte jedoch mehr Speicher, weil einige Adressbereiche doppelt und ein Bereich sogar dreifach belegt war. Zunächst waren die ganzen 64kB mit RAM belegt. Doppelt belegte Bereiche waren folgende: ab $A000 lagen außerdem 8kB Basic-ROM und ab $E000 lagen 8kB Kernal-ROM, zusätzlich konnten 8kB ab $8000 mit einem externen Modul belegt werden. Die 4kB ab $D000 waren dreifach belegt, dort gab es außer dem RAM noch 2 Zeichensätze zu je 2 kB und als dritte Belegung die Adressbereiche weiterer Chips, die folgendermaßen verteilt waren: $D000-$D3FF VIC (später VIC II) der Grafik-Chip, $D400-$D7FF SID der Sound-Chip, $D800-$DBFF das Farb-RAM ab $DC00 und $DD00 lagen noch Adressbereiche von 2 Steuerchips (CIA1 und CIA2) über die die Tastatur und wahlweise 2 Joysticks, 4 Paddles, oder 1 Lightpen abzufragen, außerdem waren dort 4 AD-Wandler abfragbar, die es ermöglichten, den C64 als Oszilloskop zu nutzen. Später konnten die Anschlüsse mit je 1 Maus belegt werden (am C64 konnten also 2 Spieler beide mit einer Maus gemeinsam ein Spiel spielen) Der C64 hatte also standardmäßig schon 88kB. Auf welchen der mehrfach belegten Bereiche man zugreifen konnte, wurde mit einem weiteren Chip, dem PLA geregelt, der nur 2 Register hatte auf die man mit den Speicherstellen $0000 (Datenregister) und $0001 (Datenrichtungsregister) zugreifen konnte. BladeRunner hat Folgendes geschrieben: Der C64 hat für jede seiner 1000 (4025) Zeichen auf dem Bildschirm ein Halbbyte an Farbram, mit welchem die einzuzeichnende Farbe festgelegt wird. Er konnte also 2^4 -> 16 Farben darstellen. Diese waren in einer festen Palette hinterlegt. Einen normalen Text in Farbe auf dem Bildschirm darzustellen 'kostete' also 1000 Byte für die Zeichen, 1000 Halbbyte für die Farbe und dann noch ein Byte für die Hintergrundfarbe des Schirms. Das ist fast richtig, das Byte für die Hintergrundfarbe war tatsächlich nur ein Halbbyte und kostete keinen Speicher, da man die Hintergrundfarbe durch Beschreiben der Speicherstelle $21 des VIC (Grafik-Chip) festlegen konnte. Außerdem war zum Schreiben von Text auch der 2kB-Zeichensatz nötig (256 Zeichen zu je 8 Byte) BladeRunner hat Folgendes geschrieben: Das war eine sehr effiziente Methode der Darstellung. Die Effizienz wurde vor allem dadurch erzielt, dass der VIC alle Grafik-Ausgaben machte und ein Programm nur Speicherstellen verändern brauchte. So konnte man beispielsweise 4 eigene Zeichensätze in dem RAM unter dem Kernal erzeugen und für den Wechsel der Zeichensätze einen der CIA-Chips programmieren und schon hatte man animierte Zeichen, ohne den Prozessor zu beanspruchen. Da auch das 1kB für den Bildschirmspeicher an fast jede 1kB-Grenze im RAM verschiebbar war, konnte man damit bereits Doublebuffering erreichen. BladeRunner hat Folgendes geschrieben: Zudem wurde das Farbram auch für Grafikmodi als eine Art Tabelle genutzt, welche Farbe pro 88 Pixel (was einem Zeichen Größe entsprach) im Vordergrund zu sehen ist. Mir ist nicht klar, was die Bemerkung aussagen soll, da das Farbram immer eine Tabelle mit Werten von 0-15 ist, die bestimmt welche der 16 möglichen Farben für einen 8x8 Pixel-Bereich gültig ist BladeRunner hat Folgendes geschrieben: Zusätzlich wurde dann im Normalen RAM noch weitere 1000Byte RAM genutzt, die noch zwei andere Farben pro Block definierten. Damit konnte der C64 pro "Zeichen" bis zu 4 Farben nutzen: Hintergrund, FarbRAM, HiNibble des externen Farbspeichers und dessen LONibble (Ein Nibble ist ein Halbbyte). Zur damaligen Zeit war diese Grafikfähigkeit revolutionär. Damit ist wohl die Hires-Darstellung gemeint, aber falsch beschrieben: Zunächst einmal gab es nicht 4 Farben für jeden 8x8-Bereich, sondern nur 3 Farben. die vierte Farbe war die Hintergrundfarbe, die für das ganze Bild gültig war und nicht für jeden 8x8-Bereich seperat eingestellt werden konnte. Außerdem wurde kein zweiter 1kB-Bereich für die Lo-Nibble/Hi-Nibble Einteilung belegt, sondern dafür wurde der normale Bildschirmspeicher genutzt. BladeRunner hat Folgendes geschrieben: Eine Grafik kostete dann 8KB RAM+ 1KB externes Farbram,das andere KB war ja intern und wurde vom VideoChip in den Adressraum des C64 gemappt. Da sind gleich mehrere Fehler: Zunächst ist das Farbram nicht extern, sondern es sind 0,5kB interner Speicher der über den VIC gesplittet wurde zu 1kB, von dem nur das untere Nibble nutzbar ist. Das andere 1kB ist wie schon erwähnt der Bildschirmspeicher. Das ist Speicher wie jeder andere Speicher auch. So könnte man beispielsweise den Bildschirmspeicher auf $C000 legen um den Anfang des Basic-Speichers um 1kB nach unten zu versetzen. eine Multicolor-Hires-Grafik kostet 8000 Bytes für Pixel (nicht 8kB), 1500 Bytes für Farben und das Byte für den Hintergrund, von dem nur ein Nibble genutzt wird, also 9501 Byte=ca.9,28kB Durch eine Spezielle Technik habe ich jedoch in einigen Demos weit mehr als die 16 Vorgabefarben verwendet, jedoch das hier zu erklären, würde zu weit führen. Der VIC mappt keine Daten in den Adressraum des C64, sondern er nutzt den gleichen Speicher wie der Prozessor, kann jedoch immer nur auf einen 16k-Block zugreifen. Der VIC wertet nur die vorhandenen Daten aus, um die Grafik gemäß seinen Registereinstellungen auf dem Bildschirm anzuzeigen. BladeRunner hat Folgendes geschrieben: Hätte man, wie bei heutigen Systemen üblich, einfach Bitplanes genommen, wäre die Grafik ungleich größer gewesen, wenn auch mit weniger Einschränkungen bei der Darstellung. Eine Grafik mit 4 Bitplanes, also 16 Farben möglich, und das für jeden einzelnen Pixel, hätte gleich mal 32KB der 64KB RAM verbraten. Stimmt! BladeRunner hat Folgendes geschrieben: Und genau darum ging es mir in diesem Contest: Die Beschränkungen sollten ein Anreiz sein zu zeigen was man alles aus wenig rausholen kann. Die Einschränkungen waren jedoch etwas zu extrem, denn auch beim C64 hat man 38kB für Programm+Variablen+Stringspeicher Interessanter würde ich es finden, wenn man den Blitz2D-Funktionssatz so weit eischränken würde, wie es das C64 war: keine Types, Funktionen, Schleifen außer For-Next, nur If-Then ohne Else und erst recht kein Select usw.

Sirrus

Do, Nov 05, 2015 8:18
Antworten mit Zitat

Das ist zwar ein Thema, das schon 2 Jahre alt ist, aber nachdem niemand BladeRunner widersprochen hat, wollte ich die teilweise falsche Darstellung der C64-Grafik nicht so stehen lassen. Ich habe seit 1982 sehr viel am C64 programmiert und kenne ihn in und auswendig.
BladeRunner hat Folgendes geschrieben:

Es ist zunächst einmal richtig, dass der C64 nur 64kB adressieren konnte, er hatte jedoch mehr Speicher, weil einige Adressbereiche doppelt und ein Bereich sogar dreifach belegt war. Zunächst waren die ganzen 64kB mit RAM belegt. Doppelt belegte Bereiche waren folgende: ab $A000 lagen außerdem 8kB Basic-ROM und ab $E000 lagen 8kB Kernal-ROM, zusätzlich konnten 8kB ab $8000 mit einem externen Modul belegt werden. Die 4kB ab $D000 waren dreifach belegt, dort gab es außer dem RAM noch 2 Zeichensätze zu je 2 kB und als dritte Belegung die Adressbereiche weiterer Chips, die folgendermaßen verteilt waren: $D000-$D3FF VIC (später VIC II) der Grafik-Chip, $D400-$D7FF SID der Sound-Chip, $D800-$DBFF das Farb-RAM ab $DC00 und $DD00 lagen noch Adressbereiche von 2 Steuerchips (CIA1 und CIA2) über die die Tastatur und wahlweise 2 Joysticks, 4 Paddles, oder 1 Lightpen abzufragen, außerdem waren dort 4 AD-Wandler abfragbar, die es ermöglichten, den C64 als Oszilloskop zu nutzen. Später konnten die Anschlüsse mit je 1 Maus belegt werden (am C64 konnten also 2 Spieler beide mit einer Maus gemeinsam ein Spiel spielen)
Der C64 hatte also standardmäßig schon 88kB. Auf welchen der mehrfach belegten Bereiche man zugreifen konnte, wurde mit einem weiteren Chip, dem PLA geregelt, der nur 2 Register hatte auf die man mit den Speicherstellen $0000 (Datenregister) und $0001 (Datenrichtungsregister) zugreifen konnte.
BladeRunner hat Folgendes geschrieben:

Der C64 hat für jede seiner 1000 (40*25) Zeichen auf dem Bildschirm ein Halbbyte an Farbram, mit welchem die einzuzeichnende Farbe festgelegt wird. Er konnte also 2^4 -> 16 Farben darstellen. Diese waren in einer festen Palette hinterlegt.
Einen normalen Text in Farbe auf dem Bildschirm darzustellen 'kostete' also 1000 Byte für die Zeichen, 1000 Halbbyte für die Farbe und dann noch ein Byte für die Hintergrundfarbe des Schirms.

Das ist fast richtig, das Byte für die Hintergrundfarbe war tatsächlich nur ein Halbbyte und kostete keinen Speicher, da man die Hintergrundfarbe durch Beschreiben der Speicherstelle $21 des VIC (Grafik-Chip) festlegen konnte. Außerdem war zum Schreiben von Text auch der 2kB-Zeichensatz nötig (256 Zeichen zu je 8 Byte)
BladeRunner hat Folgendes geschrieben:

Das war eine sehr effiziente Methode der Darstellung.

Die Effizienz wurde vor allem dadurch erzielt, dass der VIC alle Grafik-Ausgaben machte und ein Programm nur Speicherstellen verändern brauchte. So konnte man beispielsweise 4 eigene Zeichensätze in dem RAM unter dem Kernal erzeugen und für den Wechsel der Zeichensätze einen der CIA-Chips programmieren und schon hatte man animierte Zeichen, ohne den Prozessor zu beanspruchen. Da auch das 1kB für den Bildschirmspeicher an fast jede 1kB-Grenze im RAM verschiebbar war, konnte man damit bereits Doublebuffering erreichen.
BladeRunner hat Folgendes geschrieben:

Zudem wurde das Farbram auch für Grafikmodi als eine Art Tabelle genutzt, welche Farbe pro 8*8 Pixel (was einem Zeichen Größe entsprach) im Vordergrund zu sehen ist.

Mir ist nicht klar, was die Bemerkung aussagen soll, da das Farbram immer eine Tabelle mit Werten von 0-15 ist, die bestimmt welche der 16 möglichen Farben für einen 8x8 Pixel-Bereich gültig ist
BladeRunner hat Folgendes geschrieben:

Zusätzlich wurde dann im Normalen RAM noch weitere 1000Byte RAM genutzt, die noch zwei andere Farben pro Block definierten. Damit konnte der C64 pro "Zeichen" bis zu 4 Farben nutzen: Hintergrund, FarbRAM, HiNibble des externen Farbspeichers und dessen LONibble (Ein Nibble ist ein Halbbyte).
Zur damaligen Zeit war diese Grafikfähigkeit revolutionär.

Damit ist wohl die Hires-Darstellung gemeint, aber falsch beschrieben: Zunächst einmal gab es nicht 4 Farben für jeden 8x8-Bereich, sondern nur 3 Farben. die vierte Farbe war die Hintergrundfarbe, die für das ganze Bild gültig war und nicht für jeden 8x8-Bereich seperat eingestellt werden konnte. Außerdem wurde kein zweiter 1kB-Bereich für die Lo-Nibble/Hi-Nibble Einteilung belegt, sondern dafür wurde der normale Bildschirmspeicher genutzt.
BladeRunner hat Folgendes geschrieben:

Eine Grafik kostete dann 8KB RAM+ 1KB externes Farbram,das andere KB war ja intern und wurde vom VideoChip in den Adressraum des C64 gemappt.

Da sind gleich mehrere Fehler: Zunächst ist das Farbram nicht extern, sondern es sind 0,5kB interner Speicher der über den VIC gesplittet wurde zu 1kB, von dem nur das untere Nibble nutzbar ist. Das andere 1kB ist wie schon erwähnt der Bildschirmspeicher. Das ist Speicher wie jeder andere Speicher auch. So könnte man beispielsweise den Bildschirmspeicher auf $C000 legen um den Anfang des Basic-Speichers um 1kB nach unten zu versetzen. eine Multicolor-Hires-Grafik kostet 8000 Bytes für Pixel (nicht 8kB), 1500 Bytes für Farben und das Byte für den Hintergrund, von dem nur ein Nibble genutzt wird, also 9501 Byte=ca.9,28kB
Durch eine Spezielle Technik habe ich jedoch in einigen Demos weit mehr als die 16 Vorgabefarben verwendet, jedoch das hier zu erklären, würde zu weit führen.
Der VIC mappt keine Daten in den Adressraum des C64, sondern er nutzt den gleichen Speicher wie der Prozessor, kann jedoch immer nur auf einen 16k-Block zugreifen. Der VIC wertet nur die vorhandenen Daten aus, um die Grafik gemäß seinen Registereinstellungen auf dem Bildschirm anzuzeigen.
BladeRunner hat Folgendes geschrieben:

Hätte man, wie bei heutigen Systemen üblich, einfach Bitplanes genommen, wäre die Grafik ungleich größer gewesen, wenn auch mit weniger Einschränkungen bei der Darstellung. Eine Grafik mit 4 Bitplanes, also 16 Farben möglich, und das für jeden einzelnen Pixel, hätte gleich mal 32KB der 64KB RAM verbraten.

Stimmt!
BladeRunner hat Folgendes geschrieben:

Und genau darum ging es mir in diesem Contest: Die Beschränkungen sollten ein Anreiz sein zu zeigen was man alles aus wenig rausholen kann.

Die Einschränkungen waren jedoch etwas zu extrem, denn auch beim C64 hat man 38kB für Programm+Variablen+Stringspeicher
Interessanter würde ich es finden, wenn man den Blitz2D-Funktionssatz so weit eischränken würde, wie es das C64 war:
keine Types, Funktionen, Schleifen außer For-Next, nur If-Then ohne Else und erst recht kein Select usw.

Zuletzt bearbeitet von Sirrus am Do, Nov 05, 2015 11:08, insgesamt einmal bearbeitet

	BladeRunner Moderator	Do, Nov 05, 2015 9:22 Antworten mit Zitat
Respekt, Leichenschändung für C64 Fachgebashe obwohl der Contest eigentlich nur einen virtuellen Computer abbilden sollte und nicht explizit den C64, auch wenn ich den als Beispiel mit genommen hatte. Um deine Nekrophilie aber zu würdigen, folgende Anmerkungen: Ja, der C64 hat mehr als 64 KB Speicher verbaut, um genau zu sein 64K Ram, 20 K Rom (Basic, Kernal, Char-ROM) und ein halbes KB FarbRAM. Somit kommen wir also auf 84.5K (und nicht 88, wie von dir angegeben) Speicher die verbaut waren. Das ändert nichts an meiner Aussage dass man mit einem 16-Bit Datenbus nur 64K zeitgleich adressieren kann, und es ist für den Contest als solches auch völlig irrelevant wie der C64 mittels der PLA zwischen den einzelnen Ram/Rom-Bänken umschaltet. Weshalb nun die Grafikdarstellung effizient war - und das vorallem bezogen auf den Speicherverbrauch, habe ich nicht genauer ausgeführt, wil es einfach nicht nötig war. Wie schon erwähnt, es ging in dem Contest NICHT darum einen C64 zu emulieren Bezüglich FarbRAM als Tabelle: Im Multicolormodus war es durchaus so dass das FarbRAM eine Art Umschalter war: War Bit 3 des Farbnibbles gesetzt wurde überhaupt erst der Multicolor Char Mode genutzt, bei 0-7 wurde das Zeichen weiter Monochrom mit voller Auflösung dargestellt. Siehe dazu auch hier: https://www.c64-wiki.de/index.php/Multicolor Über gerundete 8000 zu 8192 Byte werde ich nicht streiten, denn weiterhin gilt dass ich nur Beispiele für den grundlegenden Aufbau geben wollte. (oder willst Du noch eine Diskussion darüber starten ob ich KB oder KiB schreiben sollte?) Beim grundsätzlichen Aufbau des Multicolor-Modus selbst habe ich auch korrekt beschrieben: Es wurde ein KB für Farbinformationen zusätzlich zu den 8KB Pixeldaten genutzt. Ich habe nicht erwähnt dass es der Bildschormspeicher ist, weil es einfach irrelevant war. Und was die speichertechnischen Begrenzungen bei diesem Contest anging sind wir da eher bei einem VCS2600, der luxuriöse 128 Byte RAM hatte, was aber weiter irrelevant ist da ich die Spezifikationen für den Contest selbst festgelegt habe. So, nun genug Korinthen gekackt? (Oder anders gefragt: geht es dir jetzt besser dabei einen Uralt-Thread auszugraben, Dinge zu erläutern die (im Thread-Zusammenhang) nicht erläuterungswürdig waren und noch dazu selbst Fehler rein zu bauen? Ich frag mich manchmal echt ob einige Leute zu viel Zeit haben.)
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Do, Nov 05, 2015 9:22
Antworten mit Zitat

Respekt,
Leichenschändung für C64 Fachgebashe obwohl der Contest eigentlich nur einen virtuellen Computer abbilden sollte und nicht explizit den C64, auch wenn ich den als Beispiel mit genommen hatte.

Um deine Nekrophilie aber zu würdigen, folgende Anmerkungen:
Ja, der C64 hat mehr als 64 KB Speicher verbaut, um genau zu sein 64K Ram, 20 K Rom (Basic, Kernal, Char-ROM) und ein halbes KB FarbRAM. Somit kommen wir also auf 84.5K (und nicht 88, wie von dir angegeben) Speicher die verbaut waren. Das ändert nichts an meiner Aussage dass man mit einem 16-Bit Datenbus nur 64K zeitgleich adressieren kann, und es ist für den Contest als solches auch völlig irrelevant wie der C64 mittels der PLA zwischen den einzelnen Ram/Rom-Bänken umschaltet.

Weshalb nun die Grafikdarstellung effizient war - und das vorallem bezogen auf den Speicherverbrauch, habe ich nicht genauer ausgeführt, wil es einfach nicht nötig war. Wie schon erwähnt, es ging in dem Contest NICHT darum einen C64 zu emulieren Wink

Bezüglich FarbRAM als Tabelle:
Im Multicolormodus war es durchaus so dass das FarbRAM eine Art Umschalter war:
War Bit 3 des Farbnibbles gesetzt wurde überhaupt erst der Multicolor Char Mode genutzt, bei 0-7 wurde das Zeichen weiter Monochrom mit voller Auflösung dargestellt.
Siehe dazu auch hier: https://www.c64-wiki.de/index.php/Multicolor

Über gerundete 8000 zu 8192 Byte werde ich nicht streiten, denn weiterhin gilt dass ich nur Beispiele für den grundlegenden Aufbau geben wollte. (oder willst Du noch eine Diskussion darüber starten ob ich KB oder KiB schreiben sollte?)

Beim grundsätzlichen Aufbau des Multicolor-Modus selbst habe ich auch korrekt beschrieben: Es wurde ein KB für Farbinformationen zusätzlich zu den 8KB Pixeldaten genutzt. Ich habe nicht erwähnt dass es der Bildschormspeicher ist, weil es einfach irrelevant war.

Und was die speichertechnischen Begrenzungen bei diesem Contest anging sind wir da eher bei einem VCS2600, der luxuriöse 128 Byte RAM hatte, was aber weiter irrelevant ist da ich die Spezifikationen für den Contest selbst festgelegt habe.

So, nun genug Korinthen gekackt? (Oder anders gefragt: geht es dir jetzt besser dabei einen Uralt-Thread auszugraben, Dinge zu erläutern die (im Thread-Zusammenhang) nicht erläuterungswürdig waren und noch dazu selbst Fehler rein zu bauen? Ich frag mich manchmal echt ob einige Leute zu viel Zeit haben.)

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	SpionAtom Betreff: Sorry for trash	Do, Nov 05, 2015 10:01 Antworten mit Zitat
Das passiert, wenn man zwei Jahre als wichtig gepinnt ist *hust*
os: Windows 10 Home cpu: Intel Core i7 6700K 4.00Ghz gpu: NVIDIA GeForce GTX 1080

SpionAtom

Betreff: Sorry for trash

Do, Nov 05, 2015 10:01
Antworten mit Zitat

Das passiert, wenn man zwei Jahre als wichtig gepinnt ist *hust*

os: Windows 10 Home cpu: Intel Core i7 6700K 4.00Ghz gpu: NVIDIA GeForce GTX 1080

Gehe zu Seite Zurück 1, 2, 3 Weiter

Übersicht

Sonstiges

Smalltalk

Nach Oben

BlitzBasic Portal

Retro-Contest Part 2

Betreff: Sorry for trash