|
DEUTSCHE VERSION |
|
 |
| Links | | | Forums | | | Comments | | | Report news |
|
| Chat | | | Polls | | | Newsticker | | | Archive |
|
| amiga-news.de Forum > Programmierung > Schnelle Grafiklibrary für AGA und GFX-Karten gesucht | [ - Search - New posts - Register - Login - ] |
| -1- | [ - Post reply - ] |
|
2008-08-10, 03:10 h PeaBrain Posts: 265 User |
Hallo. So, ich hab jetzt alles neu installiert und bevor ich anfange mit meinem projekt, hab ich mir mal so ein paar gedanken gemacht, wie die grafik eigentlich aussehen soll. im moment läuft meine workbench in 640x480 AGA. und jetzt überlege ich, was ich für eine grafikengine benutzen soll und ob ich sprites, bobs oder 3d grafik verwenden soll. ich würde mich über kommentare sehr freuen, da ich gerne anfangen möchte. gibt es obpimierte egnines für chunky oder bob's die in dem format noch effektiv laufen? scrolling der planes sollte im aga auch möglich sein, da das spiel ja auch in aga gehen soll. danke. grüße, peabrain [ - Answer - Quote - Direct link - ] |
|
2008-08-10, 04:03 h whose Posts: 2156 User |
Zitat: Also, da wirds haarig... wenn Du ohne Plane-Scrolling auskommst, taugt so ziemlich alles, was chunky einigermaßen flott verwurstet. Nachteil ist, daß Du für AGA dann c2p-Konvertierung ausführen mußt. Diverse Algorithmen findet man im Aminet. Da anscheinend auch GraKas angepeilt werden sollen, kommen nur CPU-basierte c2p-Routinen in Frage, da die Grafik im FastRAM am schnellsten im Chunky-Format aufgebaut ist und dann für AGA irgendwie ins Chip kommen muß. Ans FastRAM wiederum kommt der Blitter nicht heran, so daß CPU/Blitter-Kombi-c2p-Funktionen flachfallen. Weiterer Nachteil von RTG-AGA-Grafik ist, daß die Planar-typischen Scrolltricks sowie Sprites komplett flachfallen. Das machen die RTG-Systeme beide nicht mit (aus nachvollziehbaren Gründen). Dazu kommt, daß bei extrem vielen Objekten oder Objekten, die sich über große Teile der Bildschirmhöhe erstrecken, die OS-Blitfunktionen für AGA ziemlich unbrauchbar weil zu langsam/zu schlecht synchronisiert sind (manchmal dauert ein Blit mit 32 * 32 Pixel über alle 3 Quellen länger als ein Frame!). Da kann es durchaus sinnvoll sein, direkt auf den Chipsatz zu gehen. Damit kann man es schaffen, z.B. Blits über 3 Quellen in 64 Pixel Breite und voller Bildhöhe in einem Frame hinzubekommen und sogar noch ein paar Zyklen für Sprites und etwas Audio-DMA frei zu haben. Die CPU hat dann allerdings nicht mehr viel im ChipRAM zu melden, fast alle ChipRAM-Zyklen sind dann "aufgeraucht". Lange Rede, kurzer Sinn: Wenn Du keine getrennt zu entwickelnden Versionen haben willst, solltest Du etwas CPU-Power sowie FastRAM voraussetzen und in Chunky, ohne Sprites, arbeiten und für AGA c2p-Konvertierung vorsehen. Obacht: SDL ist für 68k unterhalb 060/60 wirklich gar nichts. Es sei denn, Du willst ne Diashow bauen. Besonders taugliche Libraries für Chunky-Grafik kenne ich keine, RTGMaster bzw. ChunkyPPC z.B. hat auch so ihre Macken. Du mußt das wohl oder übel erst einmal ausprobieren, was für Deine Zwecke am besten geeignet ist. -- ---  µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2008-08-10, 11:29 h Der_Wanderer Posts: 1229 User |
Es gibt keine Moeglichkeit, AGA und RTG ueber einen Kamm zu scheren, und gleichzeitig beides auszureizen. Dazu sind die Unterschiede viel zu gross. Auch wuerde das bedeuten, das langsamste Schiff der Flotte bestimmt das Tempo, also AGA, und die Grafikkarte wuerde sich langweilen. Sprites, Bobs und 3D Grafik ist aber ziemlich weit gestreckt. Was hast du denn genau vor, dann kann man dir vielleicht eher Tipps geben. Ich hab mich mit dem Thema bereits intensiv beschaeftigt, kan dir also eine Abschaetzung ueber die Performance geben wenn du beschreibst wie du dir das denkst Wenn es kein Scrolling haben muss, laeuft die dbl.include von Amiblitz3 auf AGA und RTG flott. Bei Scrolling bricht die Leistung von AGA allerdings ein, dann ist nur noch RTG schnell genug. Das liegt daran, dass man bei AGA Scrolling komplett anders realisieren sollte als unter RTG. Bei RTG wird massiv Speicher verschoben, was auch schnell genug ist, waehrend man bei AGA versucht, nur einen Pointer innerhalb einer Bitmap zu verbiegen, also man bewegt gar keine Datenmengen. Zusammenfassung: Ueberlege dir, wie das Projekt genau aussehen soll, im Idealfall. Dann ueberlege dir die Zielplatformen, und dann werden die Specs runtergeschnitten, falls noetig. Wenn du viel Leistng brauchst, wird dir aber ein "entweder AGA oder RTG" nicht espart bleiben. Aussnahme ist hier Software 3D, das ist ueberall langsam, solange man sich auf einem Classic bewegt. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-10, 12:53 h whose Posts: 2156 User |
Zitat: So weit stimmen wir voll überein... Zitat: ...und hier ist es Zeit für einen ersten Einwurf: Daß man das Scrolling komplett anders realisieren "sollte" hängt aber vor allem damit zusammen, daß die RTG-Systeme es oberflächlich betrachtet gar nicht erst zulassen, daß man auf einer solchen Ebene wie bei AGA "in das Geschehen eingreifen" könnte. Es spricht hardwaretechnisch wenig dagegen, Scrolling unter RTG mit den gleichen oder zumindest sehr ähnlichen "Tricks" zu realisieren. Ich habe bisher nur oberflächlich an dem Problem gekratzt, aber wenn es gelingt, den Display-Fetch-Start mit den Bordmitteln zu beeinflussen, würde auf einen Schlag eine Menge Datenschieberei überflüssig, um Scrolling zu realisieren. Ein Nachteil bleibt allerdings bestehen: Keine VBlank-Synchronisation für 68k-Maschinen, nicht einmal mit Double Buffering... Zitat: Zweiter Einwurf: Es ist schnell genug, wenn man extrem schnelle Maschinen voraussetzt. Auf Zorro2-basierenden Maschinen ist die Verschieberei des Speichers sicherlich nicht schnell genug, wenn etwas über den Bus transportiert werden muß. Schon gar nicht für höhere Auflösungen als 320 * 200 * 8. Das ist etwas anderes, wenn die Grafikdaten komplett im Speicher der GraKa liegen können, was aber in manchen Fällen einfach nicht vollständig möglich ist. Und wie oben schon erwähnt, prinzipiell könnte man auf RTG-Systemen (und damit auch Zorro2, wenn nötig) genauso arbeiten wie mit AGA und damit eine Menge Datenschieberei einsparen. Sofern die Software das zuläßt. Ansonsten stimme ich Dir voll zu. Es ist wirklich ein Jammer, daß es den Spieleprogrammierern mit CGFX/P96 so unnötig schwer gemacht wurde, nur um eine Programmierdoktrin des "kleinsten gemeinsamen Nenners" durchzusetzen, die in dem Sektor schon immer ziemlich fehl am Platze war. Nun muß man, statt direkt aufs Ziel loszugehen, mit teilweise noch finstereren Tricks an dieser Doktrin vorbeiwurschteln, um wenigstens ein bißchen echte Performance jenseits der Anwendungen zu erhalten. Wirklich schade. -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2008-08-10, 13:11 h PeaBrain Posts: 265 User |
danke. das klingt alles sehr einleuchtend. hab mir jetzt ein paar gedanken dazu machen können. also: da ich meine ppc-karte mit bvision ja wieder ausgebaut hab, weil ichs einfach nicht gebacken bekommen sie in den tower einzubauen, wird wohl die systemvoraussetzung ein 060er mit 640x480 aga sein. eine chunkyroutine, die nur teile des screens umrechnet, werde ich auch schnell in assembler zusammengebaut kriegen. rtg ist einfach zu langesam für größere bildschirme als 320x256. na mal sehen, ob das was wird. grüße [ - Answer - Quote - Direct link - ] |
|
2008-08-10, 13:57 h whose Posts: 2156 User |
Zitat: Hm, Jain... Thilo hat mit AsteroidsTR gezeigt, daß es weniger an der Bildauflösung selbst hängt, ob ein Spiel auf RTG relativ schnell oder eben recht langsam läuft. Viel hängt davon ab, wie viele Daten über den Bus geschaufelt werden müssen. Wenn Du es schaffst, einen Großteil der für den Bildaufbau nötigen Daten im Speicher der GraKa unterzubringen, dort zu halten und dann von dort ins sichtbare Bild zu bringen, hängt es nur noch von der GraKa selbst ab, wie flott das Ganze arbeitet. Bei AGA liegt der Fall für Chunky-Grafik und c2p etwas anders. Da hängt viel davon ab, wie viele DMA-Zyklen durch den Chipsatz "verbraten" werden, denn die bestimmen letztendlich darüber, wie viele Zugriffszyklen aufs Chip die CPU noch erhält. Ich kann mich dunkel entsinnen, daß es für c2p eine "natürliche" Grenze gibt, die vom Screenmode abhängig ist. Müßtest Du evtl. mal etwas suchen, diese Themen wurden früher sehr ausgiebig in diversen Foren diskutiert. Und, wie schon erwähnt, theoretisch sollten Scrolling-Tricks ähnlich denen, die für den Amiga Chipsatz ersonnen wurden, auch mit GraKas möglich sein. Einziges Manko ist absolut mangelhafte Dokumentation. Ich habe bis heute keine zuverlässige Aussage darüber gefunden, was eigentlich genau passiert, wenn man den Bitmap-Zeiger in der RasInfo-Struktur bzw. in der dort enthaltenen BitMap-Struktur "verbiegt" (was z.B. für sog. XY-Limited-Scroller interessant wäre. Die Speicherersparnis wäre nachgerade gewaltig), bzw. ob man den überhaupt "verbiegen" kann. Wenn das wie gewünscht funktioniert, gilt das dann aber auch wirklich für alle möglichen RTG-Kombinationen? Wie siehts mit Alignment-Restriktionen aus? Kann man bei allen von CGFX/P96 unterstützten Grafikkarten damit rechnen, in z.B. 8Bit-Modi den BitMap-Start relativ gefahrlos auf ungerade Adressen verlegen zu können? Wenn ja, welche Besonderheiten sind dann noch zu beachten? Bestimmt dieser Zeiger tatsächlich den Fetch-Start oder ist er für RTG etwa nur "zufällig" auf manchen Systemen funktionierende Makulatur? Fragen über Fragen und keine Antwort geschweige denn "offizielle" Hilfe in Sicht  -- --- µA1 PPC 750GX-800 A4000 PPC 604e-233[ - Answer - Quote - Direct link - ] |
|
2008-08-10, 14:37 h PeaBrain Posts: 265 User |
das hört sich ja alles nicht gerade gut an. ach egal. ich fang einfach an und werd dann mal sehen  [ - Answer - Quote - Direct link - ] |
|
2008-08-11, 12:22 h Der_Wanderer Posts: 1229 User |
@whose Deine Einwürfe muss ich zurückweisen. > aber wenn es gelingt, den Display-Fetch-Start mit den Bordmitteln > zu beeinflussen, würde auf einen Schlag eine Menge Datenschieberei > überflüssig, um Scrolling zu realisieren Das wird aber nicht gelingen, habe ich alles schon versucht. Nicht jede Graka kann sowas übrigends, weil hier die Bytes-Per-Row nicht dem Display entsprechen. > Ein Nachteil bleibt allerdings bestehen: Keine VBlank- > Synchronisation für 68k-Maschinen, nicht einmal mit Double > Buffering... Double buffering ist möglich, siehe Asteroids. VBlank synchronisierung hängt vom Grafikkartentreiber ab. Manche unterstützen das. > Zweiter Einwurf: Es ist schnell genug, wenn man extrem schnelle > Maschinen voraussetzt. Auf Zorro2-basierenden Maschinen ist die > Verschieberei des Speichers sicherlich nicht schnell genug, wenn > etwas über den Bus transportiert werden muß. Stimmt, aber gerade beim Scrollen muss ja nichts durch den ZorroII Bus, sofern die Graka genug speicher für ein Doppelgepuffertes Display hat. Und das sollte bei 640x480 doch drin sein, oder? > Sofern die Software das zuläßt. Lässt sie aber nicht. Ausserdem hat die AGA vorgehensweise den nachteil, dass man Hintergrund retten muss, wenn sie von einem Objekt überdeckt werden. Wenn man bei einer Graka alles neu blittet, kann man sich das sparen. Dann ist eine Graka auch schneller bei vielen Objekten, weil das Retten umsonst ist. Und man muss ja für den Fall optimieren, wenn viel los ist, nicht wenn wenig los ist. > Es ist wirklich ein Jammer, daß es den Spieleprogrammierern mit > CGFX/P96 so unnötig schwer gemacht wurde, Du wirst lachen, aber AmigaOS unterstütz das ganze tatsächlich. Schau dir mal die Autodocs zu ChangeScreenBuffer an. Nur wurde das sooo selten benutzt, dass es nicht gerade optimiert wurde, und andere Methoden performanter sind bzw. sein können. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-11, 12:40 h Der_Wanderer Posts: 1229 User |
@PeaBrain Deine Annahmen stimmen so nicht. Ich will dir mal was vorrechnen: ChipMem auf einem A1200 schafft etwa 4mb/sec ZorroII schafft etwa 2mb/sec. Eine CyberVision643D schafft intern etwa 100mb/sec Jetzt nehmen wir mal einen AGA screen von 640x480x8. Speicherverbrauch ist 307,2 kB. Wenn wir nur Speicher schaufeln würden, also ohne C2P, dann schaffst du maximal eine Bildwiederholrate von 13FPS. Da fehlt dann aber noch die Spiele Logik, das Blitten von Objekten usw usw., also das ist nur der reine Transfer des Bildes auf den Screen. Das bedeutet, AGA ist für 640x480 viel zu langsam, wenn du einen Full-Screen Refresh machen willst. Das einzige was möglich ist, ist mit dem Pointer Offset Trick scrollen und einzelne Objekte manipulieren. Bei ZorroII sieht es noch schlechter aus, wobei hier kein C2P gemacht werden muss, weswegen bei 3D Shootern wie Doom2 RTG und AGA etwa gleich schnell sind. Wenn du aber direkt auf der Grafikkarte arbeitest, so wie ich es bei AsteroidsTR gemacht habe, hast du etwa 25x so viel Blit-Power zur Verfügung. Allerdings geht damit nur 2D. Seien wir großzüging und nehmen einen Hi-Color Screen mit 16bit: Dann verbaucht der Bildschirm 640x480x16 = 614kB. Die CV3D macht 100MB/sec, also kann man eine FPS von 163 erreichen, schon besser, oder? Also du solltest dir erst folgende Fragen beantworten: Wie sieht mein Spiel aus? 1. 2D oder 3D? 2. Benötigt es einen Full-Screen-Refresh? (also wird jeder Frame neu gezeichnet, z.B. bei 3D notwendig) 3. Soll es Scrolling haben? 4. AGA Unterstützung, ja oder nein? Wenn es 3D oder AGA sein soll, solltest du dir 640x480 aus dem Kopf schlagen. Bei 2D wirst du für AGA und RTG verschiedene Engines brauchen, wenn du maximale Leistung haben willst. Dafür ist bei RTG durchaus 640x480x16 möglich, bei AGA aber niemals. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-11, 12:46 h Der_Wanderer Posts: 1229 User |
@whose Die Fragen in deinem letzen Posting kann man alle mit "nein, darüber darfst du keine Annahmen machen" beantworten. Möglicherweise kann das die ein oder andere Hardware, aber eben nicht alle. Z.B. habe ich mich gefragt, wie unter RTG Auto-Scroll Bildschirme Funktionieren. Die Performance bei einer CyberV64 beim Scrollen lässt aber darauf schliessen, dass Daten kopiert werden und sogar durch den ZorroII Bus müssen. Dort wird also nicht nur ein Pointer verbogen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-11, 16:07 h geit Posts: 332 [Former member] |
@PeaBrain: Ich kann dir nur empfehlen das ganze so weit auseinander zur dröseln, bis du auf einem gemeinsammen Nenner kommst und von da getrennt für RTG und ChipSet programmieren. So habe ich das bei Boulderdäsh auch gemacht. Im Chipset-Modus wird eine doppelt gepufferte Copperliste genommen, die den Blitter programmiert und von der CPU im Interrupt aktualisiert wird. Im RTG Modus habe ich einfach einen Screen geöffnet und direkt die Grafik mit der CPU in die Bitmap gerendert (incl. Scrolling. Bei 320x200 ist das auf einem 68030-25 flüssig. In beiden Modi wird das Bild 50 bzw. 60 mal pro Sekunde komplett aktualisiert. Scrollen durch verschieben ist rechenzeit Verschwendung, da theoretisch jeder Pixel sich geändert haben kann. Der RTG-Fenstermodus ist noch einfacher. Da habe ich nur einen Speicherbereich im RAM genommen, der von der normalen RTG Routine gerendert wird. Das fertige Bild wird dann ins Fenster geblittet. Chunky-Planar Umrechnung im Spiel gibt es keine. Die Grafiken werden beim Start eingeladen und je nach Modus umgerechnet. Geit [ Dieser Beitrag wurde von geit am 11.08.2008 um 16:09 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-08-11, 18:05 h PeaBrain Posts: 265 User |
Hallo, und danke erstmal an alle. ich muss mir das alles noch genauer ansehen. aber wie es scheint, werde ich wohl nicht um meine graka drum rum kommen. aber dazu muss ich erstmal die ppc-karte wieder in den rechner bekommen und die bvision gekühlt. denn sonst kann ich das vergessen. grüße [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 12:22 h Der_Wanderer Posts: 1229 User |
PeaBrain Erzähl doch mal, was du genau vorhast, dann kann dir hier viel besser geholfen werden. Viele der Leute hier haben sich darüber schon intensiv Gedanken gemacht, und können dir dadurch jede Menge Rumprobiererei (und damit möglicherweise das Einstellen des Projekts) ersparen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 14:48 h Andreas_Wolf Posts: 2980 User |
> Erzähl doch mal, was du genau vorhast Ich vermute, es geht immer noch um das hier. [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 16:17 h Der_Wanderer Posts: 1229 User |
Hm also wenn PeaBrain das vorhat, dann wohl eher 320x240, oder was für eine Auflösung hat das DS? Also ich würde das ganze mit Amiblitz für Graka umsetzen in 24bit, da muss man sich keinen Kopf um Leitung und Paletten machen. Wenn das ganze dan funzt, kann man es einfach mal auf AGA probieren. Wenn es aktzeptabel ist, dann schön, ansonsten, wenn der Ehrgeiz noch da ist, kann man es optimieren. Machbar ist das auf jeden Fall, sowohl auf Graka als auch AGA. Nur erfordert AGA ein wenig mehr Optimierungsarbeit. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 16:30 h Andreas_Wolf Posts: 2980 User |
> was für eine Auflösung hat das DS? 256*192. [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 16:53 h Holger Posts: 8116 User |
Zitat: Mal zwei. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 17:56 h PeaBrain Posts: 265 User |
Hallo. Ja, das ist korrekt. genau das habe ich vor. eigentlich schon seid längerem. mein chef möchte das ding nicht auf dem ds veröffentlichen, weil es nicht zu unserem firmenprofil passt. naja und ich willst nicht verkommen lassen. und da ich ein amiga- fan bin, wollt ich es auf dem amiga umsetzen. doch hardware-probleme haben mich bis jetzt davon abgehalten. hab jetzt ne kühlung für meine bvision besorgt und für die ppc-karte werd ich mir intern auch noch was einfallen lassen. werde wohl versuchen sie mit einem riesigen passivkühler zu kühlen. so hab ich nicht das problem, daß mein lüfter im desktop aufsetzen kann. hoffe das klappt.  gruß [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 18:57 h Der_Wanderer Posts: 1229 User |
> wollt ich es auf dem amiga umsetzen. doch hardware-probleme haben mich bis jetzt davon abgehalten. Vielleicht wäre WinUAE eine Option für dich, zumindest zum Entwickeln ist es doch eine grosse Erleichterung etwas mehr Pferde unter der Haube zu haben und eine hohe Auflösung. Dort kannst du auch gleich AGA Kompatibelität etc. testen, ohne die Hardware aus dem Keller zu holen. Nur für den Speed-Test wird du das dann tun müssen. -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 20:02 h PeaBrain Posts: 265 User |
hab ja winuae installiert. aber irgendwie haut das mit der uaegfx bei mir nicht hin. hatte 3.9 installiert. hab aber die picasso emulation nicht hinbekommen. außerdem hab ich ja meine 1200er nicht im keller zu stehen hab beide oben  gruß [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 20:28 h Der_Wanderer Posts: 1229 User |
Das mit uaegfx klappt schon. check mal 1. RTG Memory sollte eingestellt sein, am besten 64MB. 2. uaegfx + .info sollten in DEVS:Monitors sein 3. Die rtg.library von der WinUAE Distro sollte in LIBS:Picasso96 sein, genauso wie die uae.card Dann sollte es funktionieren. Hab ich was vergessen? Es lohnt sich... -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-12, 23:33 h PeaBrain Posts: 265 User |
hehe, ok, danke, das hat jetzt echt geklappt. ich hatte also nur keinen rtg speicher sowas muss man erstmal wissen kann ich damit jetzt auch opengl programmieren? [ - Answer - Quote - Direct link - ] |
|
2008-08-13, 10:27 h Holger Posts: 8116 User |
Zitat:Jein. Es gibt eine lowlevel-Schnittstelle namens Warp3D und auch einen passenden Wrapper, der diese Funktionen in WinUAE nachbildet. Darauf aufsetzend hast Du die Wahl zwischen StormMesa, einer Mesa-Portierung mit der für Mesa bekannten Effizienz und miniGL, einem schlankeren openGL-Subset. Da bei dem Wrapper für WinUAE auch eine angepasste Mesa-Bibliothek beiliegt, sollte man sich nicht von der möglicherweise brauchbaren Performance zu sehr beeindrucken lassen--da ist auf jeden Fall ein Test auf einem realen Amiga nötig, bevor man sich entscheidet, Mesa zu benutzen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Answer - Quote - Direct link - ] |
|
2008-08-13, 11:51 h Der_Wanderer Posts: 1229 User |
Es gibt für Amiblitz eine opengl.include, aber die ist noch nciht fertig und eher als Codebeispiel zu sehen. Prinzipiell geht das, ja. Aber das ist noch unerforschtes Gebiet, und wie Holger schon meinte, auf einem Classic würde ich selbst mit 3D Hardware keine allzugrossen Erwartungen haben. Ich erinnere mich noch an die Demos für die Cybervision64 3D. Sah schön aus, aber leider nur als Standbild... -- Thilo Köhler, Author von: HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, TK AB3 Includes und viele mehr... Homepage: http://www.hd-rec.de [ - Answer - Quote - Direct link - ] |
|
2008-08-13, 16:19 h Andreas_Wolf Posts: 2980 User |
> Es gibt eine lowlevel-Schnittstelle namens Warp3D und auch > einen passenden Wrapper, der diese Funktionen in WinUAE > nachbildet. Ergänzung: Es gibt auch noch die Warp3D-Reimplementierung Wazp3D, die allerdings nur Software-Rendering unterstützt. Dafür benötigt sie keinen Wrapper wie das echte Warp3D, ist aber natürlich langsamer. Wer Probleme mit Warp3D + Wrapper hat (der Wrapper hat Probleme mit einigen GraKas), kann diese Lösung versuchen. [ Dieser Beitrag wurde von Andreas_Wolf am 13.08.2008 um 16:21 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
|
2008-08-16, 19:41 h Mad_Dog Posts: 1944 User |
Zitat: Nichts gegen die Basic-Fans hier, aber mit C tut man sich in diesem Fall wesentlich leichter, denn in den StormMesa Archiven sind schon die benötigten Includes und Linker-Libs für gängige C-Compilier enthalten. Außerdem kann man auf einen riesen Fundus an C-Quellcodes zum Thema zurückgreifen. Zum einen werden schon bei den StormMesa Archiven tonnenweise C-Beispielsources mitgeliefert. Zum anderen wird man im Netz auch schnell fündig, wenn es um C-Programmierung mit OpenGL geht, z.B. auf http://nehe.gamedev.net/ Zitat: Unerforscht würde ich nicht sagen - immerhin gab es einige Spiele mit Unterstützung von 3D-Beschleunigern. Aber Du hast natürlich Recht: Wunder kann man auf der Classic-Hardware in Sachen 3D-Beschleunigung nicht erwarten. Zitat: Wie gesagt: Bei StormMesa sind viele Demos dabei, die - entsprechend Leistungsfähige Hardware vorausgesetzt - schon über eine "Diashow" hinausgehen. Ein paar sehr einfache Beispiele findet Ihr auch auf meiner Homepage unter Amiga-Stuff. -- http://www.norman-interactive.com [ Dieser Beitrag wurde von Mad_Dog am 16.08.2008 um 19:45 Uhr geändert. ] [ - Answer - Quote - Direct link - ] |
| -1- | [ - Post reply - ] |
| amiga-news.de Forum > Programmierung > Schnelle Grafiklibrary für AGA und GFX-Karten gesucht | [ - Search - New posts - Register - Login - ] |
|
|
Masthead |
Privacy policy |
Netiquette |
Advertising |
Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved. |
|