amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Frage bzgl. Amiga-Technologie [ - Suche - Neue Beiträge - Registrieren - Login - ]

-1- [ - Beitrag schreiben - ]

04.02.2003, 11:02 Uhr

Petra
Posts: 1121
Nutzer
Ich habe von Certain von Tukult eine Frage gestellt bekommen, die ich
leider nicht beantworten kann. Wer kann weiterhelfen?

Ciao, Petra


http://www.tukult.de/



++++
Hallo Petra,

Du erinnerst Dich vielleicht noch an unser Projekt "Tukult - The Space Rat Adventure", über das amiga-news.de vor einiger Zeit in einem Newsartikel berichtete. Uns stellte sich kürzlich eine Frage bzgl. Amiga-Technologie, die wir im Team nicht beantworten konnten, und so wollte ich mich einfach mal an einen Amiga-Experten wenden.

Im Moment geht die Entwicklung unserer Engine mit großen Schritten voran. Wie bereits angekündigt werden wir unsere Bemühungen zunächst auf eine Win32-Version konzentrieren, aber natürlich wollen wir andere Versionen zumindest im Hinterkopf haben.

Derzeit stehen bei uns im Team mehrere Entscheidungen bzgl. zu verwendender Technologien an. Die Frage, die ich im Moment gerne geklärt hätte: steht auf Amiga-Systemen OpenGL zur Verfügung? Falls ja, gibt es irgendwelche Einschränkungen?

Es wäre wirklich sehr nett, wenn Du uns weiterhelfen würdest. Wir haben aktuell leider keine Zeit, uns in die Amiga-Materie einzuarbeiten, wollen uns aber die Möglichkeit einer Umsetzung offen halten.

Bye,

~ Certain

[- Tukult webmaster + projectleader -]

ICQ: 120283587
---

Adventure isn't dead! -|- Visit http://www.tukult.de
++++

[ Dieser Beitrag wurde von Petra am 05.01.2005 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 12:58 Uhr

westpdmkids
Posts: 168
Nutzer
MiniGL unter Warp3D.

Ist aber eine abgespeckte Version von OpenGL, glaub ich.

--
SiegNatur

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 13:01 Uhr

mrbbc
Posts: 101
Nutzer
Also OpenGL existiert, woher der Port stammt und wie gut er ist - keine Ahnung. Abgesehen davon dürfte das Hauptproblem darin liegen, was für eine Hardware darunter werkelt.

Da kann man keine zu großen Sprünge erwarten - wenn man von den neuen Amigas absieht. Stichwort sei hier: Quake 2.

Drüber bin ich grad' so gestolpert:

http://www.amiga-magazin.de/magazin/a04-97/cyber.html


Wichtiger: es gibt SDL für AmigaOS. Diese Bibliothek bietet sich für die Spieleentwicklung an.

http://www.libsdl.org


Leider gibt es in der SDL keine Mausabfrage, ansonsten könnte man damit Spiele komplett plattformunabhängig programmieren. Überhaupt weiss ich nicht, wieviel unter AmigaOS von der SDL schon implementiert ist; so manche Portierung ist unvollständig.

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 14:07 Uhr

Certain
Posts: 5
Nutzer
Zitat:
Original von mrbbc:
Wichtiger: es gibt SDL für AmigaOS.


Bisher setzen wir bei unserer Engine komplett auf SDL. Leider sind wir aber mittlerweile an die eine oder andere Grenze gestoßen. Z.B. möchten wir gerne für diverse Fading-Effekte Alphablending einsetzen. Leider arbeitet SDL hierbei extrem langsam, da die Beschleunigerfunktionen moderner Grafikkarten "ignoriert" werden.

So kamen wir dann auf den Gedanken, trotz der 2D-"Natur" des Spiels OpenGL einzusetzen. Es wäre dann natürlich schön, trotzdem auch eine Amiga-Version produzieren zu können.

Zitat:
Original von mrbbc:
Leider gibt es in der SDL keine Mausabfrage


Zumindest unter den Win32- und Apple-Versionen von SDL kann man MouseEvents abfragen. Oder meintest Du den Amiga-Port?

Bye,

~Certain

---
visit http://www.tukult.de
---

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 14:16 Uhr

westpdmkids
Posts: 168
Nutzer
Versucht doch die FadingEffekte auch per SDL zu managen.
So ist ein Port sicherlich machbarer.
Die Beschleunigung könnt man dann ja hinterher Amiga-spezifisch integrieren.

Naja, ich red schon wieder wirr ;)
--
SiegNatur

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 14:42 Uhr

Petra
Posts: 1121
Nutzer
Gerade ist mir bei der Recherche zu einem anderen Thema noch diese
Website über den Weg gelaufen:

A new original MiniGL-game coming soon, check features,
requirements and hype from:

http://www.nic.fi/~varsa/hype.html


Features

o A new original Amiga title!
o Fast 3D-accelerated graphics! (via MiniGL!)
o Cool Floating Camera and Incredible Blending Effects!
o Runs on Fullscreen or in a Window - You decide!
o Earth-shaking sound-effects! (via AHI!)
o Endless Fun, new unique levels on Every Game!
o Unbeatable gameplay, with keyboard or joystick!
o Simple, addictive and easy to learn, everyone can play!
o No needless violence!
o Coming soon to an Amiga near You!

Requirements

o An Amiga (or compatible?) with 68040+ or PPC (WarpOS)
o Warp3D (uses MiniGL)
o AHI
o Lucyplay.library
o (+some others)








--
[°¿°] Ciao, Petra

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 14:45 Uhr

westpdmkids
Posts: 168
Nutzer
Alybox ;)

Klingt interessant, nur:was ist es ? ?(

Gemessen an den Screens der anderen Spiele auf der Page, eine Art neues Denkspiel.
Cool.... ;)
--
SiegNatur

[ Dieser Beitrag wurde von westpdmkids am 04.02.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 14:54 Uhr

Petra
Posts: 1121
Nutzer
http://www.nic.fi/~varsa/author/index.html
--
[°¿°] Ciao, Petra

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 16:03 Uhr

Mad_Dog
Posts: 1944
Nutzer
Es gibt Storm MESA von Haage&Partner.
Das entspricht IMHO OpenGL V1.2 .
Wieviel Performance Du herauskriegst, hängt von der verwendeten
(3D) Graphikkarte und von der CPU (68k oder PPC) ab.
GLUT ist übrigens auch mit dabei, damit kannst Du portable
Highlevel IO implementieren (z.B. für Fenster, Mouse, Joystick,
Tastatur).
Warp3D ist das Bindeglied zwischen OpenGL und der Hardware.
Leider hat Haage&Partner die StormMesa-Page herausgenommen, aber wenn
Du dem Admin ne Mail schreibst, schickt er Dir sicher die Files (sind
recht groß). Einige kleine OpenGL Demos von mir findest Du im Aminet
oder auf meiner Homepage.


[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 16:33 Uhr

westpdmkids
Posts: 168
Nutzer
@AndreasM
Packt doch Imubox und Menobox(ein paar Posts weiter oben) auf die nächste AFuture-CD.

Würd mich mal interessieren...
--
SiegNatur

[ Dieser Beitrag wurde von westpdmkids am 04.02.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 16:47 Uhr

Certain
Posts: 5
Nutzer
Zitat:
Original von westpdmkids:
Versucht doch die FadingEffekte auch per SDL zu managen.
So ist ein Port sicherlich machbarer.

Das Problem ist, dass die mit SDL gecodeten Fadings auf jedem ausgetesten Rechner (bislang nur Win32-PCs) unfassbar langsam sind, solange das Programm im Fullscreen läuft, und eine wirklich praktikable Lösung ist mir nicht bekannt.
Ich arbeite dezeit an einem Entwurf für die Weiterentwicklung unserer Engine, der es zulässt, zwischen OpenGL und SDL (mit entsprechend angepassten Effekten) zu wählen. Doch das ist natürlich wesentlich mehr Arbeit, als einfach komplett auf OpenGL zu setzen.
Da wir aber (zumindest irgendwann) auch eine Amiga-Fassung im Sinn haben, möchten wir den Code so gestalten, dass wir hinterher nicht alles komplett ändern/anpassen müssen.

Zitat:
Original von Mad_Dog:
Es gibt Storm MESA von Haage&Partner.
Das entspricht IMHO OpenGL V1.2 .

Danke für den Tipp! :) Da werde ich mich mal drum kümmern...

Deine Homepage konnte ich übrigens nicht aufrufen, ist die URL in Deinem Profil vielleicht nicht mehr aktuell?

Bye,

~Certain

---
visit http://www.tukult.de

---

[ - Antworten - Zitieren - Direktlink - ]

04.02.2003, 16:59 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von Mad_Dog:
Es gibt Storm MESA von Haage&Partner.
Das entspricht IMHO OpenGL V1.2 .

Danke für den Tipp! :) Da werde ich mich mal drum kümmern...

Deine Homepage konnte ich übrigens nicht aufrufen, ist die URL in Deinem Profil vielleicht nicht mehr aktuell?

[/quote]

Die URL ist aktuell!

http://www.norman-interactive.com


oder alternativ:

http://w3studi.informatik.uni-stuttgart.de/~walternn/


Da findest Du im Download-Bereich 100% portable OpenGL Source Codes,
die ich sowohl auf meinem Amiga 4000/030 mit Cybervision64/3D,
als auch auf einem PentiumIII/600 PC mit GForce 4 Graphikkarte unter
Red Hat Linux getestet habe (ohne eine Zeile Code zu ändern).

Im Aminet findest Du noch einige weitere Sources (samt 68k
Executables) von mir, bei denen zusammen mit OpenGL Teilen auch
Amiga-spezifisches Zeug verwendet wird.
Geb dazu einfach mal in die Aminet-Suchmaschine OpenGL ein.
Die Mesa-Version die Du im Aminet findest, ist übrigens nicht das
Storm Mesa, das ich meine.

Aminet URL: http://de.aminet.net



[ - Antworten - Zitieren - Direktlink - ]

05.02.2003, 12:54 Uhr

mrbbc
Posts: 101
Nutzer
Hmmm... da seh' ich keine bessere Lösung als das Alphablending von Hand zu Fuss zu programmieren...

Mit der SDL kann man ja direkt auf die Grafikdaten zugreifen.

Läuft das Spiel in 8, 15, 16 oder 24 bpp ?

Kommt natürlich auch drauf an, wie oft ihr auf Alphablending zurückgreifen wollt. Vielleicht ist die SDL da schon nicht unoptimiert... eigentlich merkwürdig, wenn sie dafür nicht DirectX benutzt...

Ein Testprogramm sollte Klarheit schaffen, was schneller geht...

Man kann's auch mit einer Anfrage bei den Programmierern von Win-SDL probieren; die werden aber auf alle Fälle noch einige Zeit brauchen.

[ - Antworten - Zitieren - Direktlink - ]

05.02.2003, 13:06 Uhr

Certain
Posts: 5
Nutzer
Zitat:
Original von mrbbc:
Hmmm... da seh' ich keine bessere Lösung als das Alphablending von Hand zu Fuss zu programmieren...
Mit der SDL kann man ja direkt auf die Grafikdaten zugreifen.

Da liegt dann auch das Problem: wenn ich eine z.B. transparente Grafik auf eine andere blitten will, muss ich jeden Pixel, den ich übermalen will, vorher von der unteren Grafik einlesen. Tja, und dieser Lesevorgang ist bei Hardwaresurfaces leider ziemlich langsam unter SDL. Schneller wirds nur durch Softwaresurfaces, aber dann wird das Spiel insgesamt langsamer... ?(

Zitat:
Original von mrbbc:
Läuft das Spiel in 8, 15, 16 oder 24 bpp ?

Unsere erste Version mit 16 bpp, das ist aber noch nicht definitiv.

Bye,

~Certain

---
visit http://www.tukult.de

---

[ - Antworten - Zitieren - Direktlink - ]

05.02.2003, 17:20 Uhr

Holger
Posts: 8116
Nutzer
Mesa fuer einfache Blending-Effekte ist mit Kanonen auf Spatzen geschossen und vermutlich auch nicht sehr effizient. Deshalb existieren diese MiniGL-Varianten. Fuer diesen Zweck sollte die Funktionalitaet ausreichen.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

05.02.2003, 19:35 Uhr

Mad_Dog
Posts: 1944
Nutzer
OpenGL (bzw. StormMesa) oder MiniGL bieten beide nette Funktionen für
Transparenz. Da mußt Du dann nix mehr von Hand machen.
MiniGL ist eine abgespeckte OpenGL Variante, dafür aber schneller und
näher an der Hardware. Nachteil von MiniGL: Du mußt vieles von Hand
machen. Was willst Du eigentlich machen? Fake-Lensflares und
Transparente Polygone, oder einfach nur nen Fade/Plasma Effekt?
Für Fade- bzw. Plasma Effekte kannst Du auch ein Fenster/Screen
im CLUT Mode öffnen und dann die CLUT verändern (ich spreche hier
nicht von Copper-Effekten ;-) ).



[ - Antworten - Zitieren - Direktlink - ]

05.02.2003, 23:26 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Mad_Dog:
Was willst Du eigentlich machen? Fake-Lensflares und
Transparente Polygone, oder einfach nur nen Fade/Plasma Effekt?

Ich hatte es eher so verstanden, daß er halbtransparente Objekte auf den schon vorhandenen Bildschirminhalt legen will. Also im Prinzip nur konvexes Viereck ohne Transformation mit Textur + Alpha auf den Schirm bringen. Das könnte prinzipiell auch Warp3D ohne Zusatz, das wäre dann aber nicht mehr portabel. Also MiniGL.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

06.02.2003, 12:34 Uhr

mrbbc
Posts: 101
Nutzer
Zitat:
Original von Certain:
Da liegt dann auch das Problem: wenn ich eine z.B. transparente Grafik auf eine andere blitten will, muss ich jeden Pixel, den ich übermalen will, vorher von der unteren Grafik einlesen. Tja, und dieser Lesevorgang ist bei Hardwaresurfaces leider ziemlich langsam unter SDL. Schneller wirds nur durch Softwaresurfaces, aber dann wird das Spiel insgesamt langsamer... ?


Zum einen könnte man die Grafikdaten komplett als Bitmap ausschneiden, zum anderen sollte man so oder so unbedingt eine Softwaresurface verwenden - für "flackerfreie Grafik".

Wenn die SDL-Implementierung diesbezüglich lahm wäre, müsste man allerdings einen eigenen logischen Bildschirm anlegen auf dem man werkelt, und den dann ständig in die Hardware rüberblitten.

Grundsätzlich sieht das dann flotter aus, obwohl es -zwar unwesentlich- länger braucht[1]; das Problem ist hier aber der Arbeitsaufwand. Die SDL-Funktionen selbst funktionieren ja nur in einer SDL_Surface.

Wenn man mehr braucht, als diese Blitting-Funktion, z.B. Linien und Text, dann könnt's haarig werden.

Folglich sollte man einen Geschwindigkeitstest schreiben.

Noch ein Tipp: versucht mal, ob auf den Zielplattformen 15 bpp unterstützt werden. 16 bpp sind vielleicht etwas langsamer, weil der Grünwert 6 statt 5 Bits breit ist.

[1] In der Homecomputerzeit war das der Obertrick, um die Spielegrafik "flüssig" hin zu kriegen. Denn man konnte nicht mehr mit bekommen, wie der Bildschirm aufgebaut/gezeichnet wurde, sondern hatte satte, vollständige Bilder.

Heute bringt das natürlich nur noch wenig; bei Egoshootern kann man's abschalten, um statt 79 84 fps zu kriegen...

Grundsätzlich ist es nur eine simple Schiebeoperation von z.B. 800x600x2 Bytes - über so eine Lapalie im Laufzeitbedarf denkt heute kein Programmierer mehr nach.

[ - Antworten - Zitieren - Direktlink - ]

06.02.2003, 12:53 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von mrbbc:
Zitat:
Original von Certain:
Da liegt dann auch das Problem: wenn ich eine z.B. transparente Grafik auf eine andere blitten will, muss ich jeden Pixel, den ich übermalen will, vorher von der unteren Grafik einlesen. Tja, und dieser Lesevorgang ist bei Hardwaresurfaces leider ziemlich langsam unter SDL. Schneller wirds nur durch Softwaresurfaces, aber dann wird das Spiel insgesamt langsamer... ?


Zum einen könnte man die Grafikdaten komplett als Bitmap ausschneiden, zum anderen sollte man so oder so unbedingt eine Softwaresurface verwenden - für "flackerfreie Grafik".

Wenn die SDL-Implementierung diesbezüglich lahm wäre, müsste man allerdings einen eigenen logischen Bildschirm anlegen auf dem man werkelt, und den dann ständig in die Hardware rüberblitten.

Grundsätzlich sieht das dann flotter aus, obwohl es -zwar unwesentlich- länger braucht[1]; das Problem ist hier aber der Arbeitsaufwand. Die SDL-Funktionen selbst funktionieren ja nur in einer SDL_Surface.

Wenn man mehr braucht, als diese Blitting-Funktion, z.B. Linien und Text, dann könnt's haarig werden.



Das mit dem "Flackern" sollte kein Problem darstellen. Da benutzt man
dann einfach Double Buffering: Alle Zeichenoperationen werden auf
einem logischen (und unsichtbaren) Puffer ausgeführt und dannach
auf den physikalischen Screen geswapt. Aber was red ich mir da den
Mund fusselig (?) das kennt jeder, der schonmal irgendwas mir
animierter Grafik programmiert hat. Unter OpenGL gibts da einfach zu
benutzende High-Level Routinen. Mit MiniGL kenn ich mich nicht so
genau aus, kann sein, daß man da das Double Buffering von Hand machen
muß.
Habe hier auch jede Menge Demo-Sources. Soll ich mal was zum Thema
"Transparenz" hier posten? Ansonsten verweise ich auf die Bücher "The
OpenGL Programming Guide" und "OpenGL Game Programming", sowie die
Internetseiten von http://www.gamedev.net .

[ - Antworten - Zitieren - Direktlink - ]

06.02.2003, 13:06 Uhr

Mad_Dog
Posts: 1944
Nutzer
Hier kommt ein 2D Alpha Blending Beispiel aus "The OpenGL Programming
Guide" , auch bekannt als "The Red Book":


code:
/*
 * Copyright (c) 1993-1997, Silicon Graphics, Inc.
 * ALL RIGHTS RESERVED 
 * Permission to use, copy, modify, and distribute this software for 

/*
 *  alpha.c
 *  This program draws several overlapping filled polygons
 *  to demonstrate the effect order has on alpha blending results.
 *  Use the 't' key to toggle the order of drawing polygons.
 */
#include <GL/glut.h>
#include <stdlib.h>

static int leftFirst = GL_TRUE;

/*  Initialize alpha blending function.
 */
static void init(void)
{
   glEnable (GL_BLEND);
   glBlendFunc (GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
   glShadeModel (GL_FLAT);
   glClearColor (0.0, 0.0, 0.0, 0.0);
}

static void drawLeftTriangle(void)
{
   /* draw yellow triangle on LHS of screen */

   glBegin (GL_TRIANGLES);
      glColor4f(1.0, 1.0, 0.0, 0.75);
      glVertex3f(0.1, 0.9, 0.0); 
      glVertex3f(0.1, 0.1, 0.0); 
      glVertex3f(0.7, 0.5, 0.0); 
   glEnd();
}

static void drawRightTriangle(void)
{
   /* draw cyan triangle on RHS of screen */

   glBegin (GL_TRIANGLES);
      glColor4f(0.0, 1.0, 1.0, 0.75);
      glVertex3f(0.9, 0.9, 0.0); 
      glVertex3f(0.3, 0.5, 0.0); 
      glVertex3f(0.9, 0.1, 0.0); 
   glEnd();
}

void display(void)
{
   glClear(GL_COLOR_BUFFER_BIT);

   if (leftFirst) {
      drawLeftTriangle();
      drawRightTriangle();
   }
   else {
      drawRightTriangle();
      drawLeftTriangle();
   }

   glFlush();
}

void reshape(int w, int h)
{
   glViewport(0, 0, (GLsizei) w, (GLsizei) h);
   glMatrixMode(GL_PROJECTION);
   glLoadIdentity();
   if (w <= h) 
      gluOrtho2D (0.0, 1.0, 0.0, 1.0*(GLfloat)h/(GLfloat)w);
   else 
      gluOrtho2D (0.0, 1.0*(GLfloat)w/(GLfloat)h, 0.0, 1.0);
}

/* ARGSUSED1 */
void keyboard(unsigned char key, int x, int y)
{
   switch (key) {
      case 't':
      case 'T':
         leftFirst = !leftFirst;
         glutPostRedisplay();   
         break;
      case 27:  /*  Escape key  */
         exit(0);
         break;
      default:
         break;
   }
}

/*  Main Loop
 *  Open window with initial window size, title bar, 
 *  RGBA display mode, and handle input events.
 */
int main(int argc, char** argv)
{
   glutInit(&argc, argv);
   glutInitDisplayMode (GLUT_SINGLE | GLUT_RGB);
   glutInitWindowSize (200, 200);
   glutCreateWindow (argv[0]);
   init();
   glutReshapeFunc (reshape);
   glutKeyboardFunc (keyboard);
   glutDisplayFunc (display);
   glutMainLoop();
   return 0;
}



[ - Antworten - Zitieren - Direktlink - ]

06.02.2003, 16:37 Uhr

Certain
Posts: 5
Nutzer
[quote]
Original von mrbbc:
Zitat:
Zum einen könnte man die Grafikdaten komplett als Bitmap ausschneiden, zum anderen sollte man so oder so unbedingt eine Softwaresurface verwenden - für "flackerfreie Grafik".
Dank Doublebuffer kein Problem (stand ja schon in einem anderen Post).
[quote]
Original von mrbbc:
Zitat:
Wenn die SDL-Implementierung diesbezüglich lahm wäre, müsste man allerdings einen eigenen logischen Bildschirm anlegen auf dem man werkelt, und den dann ständig in die Hardware rüberblitten.
Alles schon versucht... durch das Blitten von Software nach Hardware geht jede Menge Geschwindigkeit flöten. Leider...

Bye,

~Certain

---
visit http://www.tukult.de

---





[ - Antworten - Zitieren - Direktlink - ]

06.02.2003, 18:14 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Zum einen könnte man die Grafikdaten komplett als Bitmap ausschneiden, zum anderen sollte man so oder so unbedingt eine Softwaresurface verwenden - für "flackerfreie Grafik".
Dank Doublebuffer kein Problem (stand ja schon in einem anderen Post).
[/quote]

O.K. , damit klar wird, von was wir hier überhaupt reden, ein kleines,
ganz einfaches Double Buffer Beispiel:

code:
/*  Turtle-Graphics Demo
 *  Norman Walter, Universität Stuttgart
 *  Rev. 1.1 (1.9.2001)
 */


#include <stdio.h>
#include <math.h>
#include <GL/glut.h>

struct Cursor
// Cursor Koordinaten und Winkel (="Blickrichtung")
{
 double X;  // Cursor X
 double Y;  // Cursor Y
 double A;  // Winkel
};

struct Cursor Turtle;

struct Destination
// Zielkoordinaten
{
  double X;  // Ziel X
  double Y;  // Ziel Y
};

struct Destination Target;

double go = 5.0;
double speedup = 25.0;

void malen(void);
void draw_lines(double X0, double Y0, double X1, double Y1);
void move(void);
void refresh(void);

int main(int argc, char **argv)
{
  // initialisierung des Cursors

  Turtle.X = 200.0;
  Turtle.Y = 150.0;
  // Turtle.A = 90.0;

  // initialisierung der Zielkoordinaten

  Target.X = 0.0;
  Target.Y = 0.0;

  glutInit(&argc, argv);

  // Double Buffer Mode
  glutInitDisplayMode(GLUT_DOUBLE|GLUT_RGB);

  glutInitWindowSize(400,300);
  glutInitWindowPosition(100,100);
  glutCreateWindow("Turtle-Graphics");
  glClearColor(0.0, 0.0, 0.0, 0.0);

  glMatrixMode(GL_PROJECTION);
  glLoadIdentity();

  glOrtho(-400.0, 400.0, -300.0, 300.0, -1.0, 1.0);
  glutDisplayFunc(&malen);

  glutIdleFunc(&refresh);
  glutMainLoop();

  return(0);
}

void malen(void)
{

  int i;
  double rotate;

  glClear(GL_COLOR_BUFFER_BIT);

  Turtle.X = 0.0;
  Turtle.Y = 0.0;
  Turtle.A = 90.0;

  for (i = 1; i < 1000; i++)
  {
    move();              // neue koordinaten berechnen
    Turtle.A += rotate;  // Cursor rotieren
    rotate += speedup;       // Rotationsgeschwindigkeit erhöhen

  // Hier wird die Funktion draw_lines aufgerufen
  // Eingabe X0, Y0, X1, Y1
  draw_lines(Turtle.X,Turtle.Y,Target.X,Target.Y);

  }

  glFinish();
  glutSwapBuffers();

}

void refresh(void)
{
 speedup += 1./3600.;
 glutPostRedisplay();
}

void draw_lines(double X0, double Y0, double X1, double Y1)
/* Zeichnet eine Linie */
{
    glBegin(GL_LINES);
    glColor3f(1.0,0.0,0.0);
    glVertex2f(X0,Y0);
    glVertex2f(X1,Y1);
    glEnd();

    // Cursor auf Zielkoordinaten verschieben
    Turtle.Y=Target.Y;
    Turtle.X=Target.X;
}

void move(void)
/* Berechnet neue Start- und Zielkoordinaten */
{
  Target.Y=sin(Turtle.A/180.0*PI)*go+Turtle.Y; // Delta Y
  Target.X=cos(Turtle.A/180.0*PI)*go+Turtle.X; // Delta X
}


Dies sollte das allgemeine Problem Double Buffering verdeutlichen:
Auf den unsichtbare, logischen Screen werden die Linien gezeichnet,
wenn alle Linien gezeichnet sind, wird geswapt, dannach beginnt das
Ganze wieder von vorne. die
code:
glutIdleFunc()

berechnet nur
die neuen Werte... das Ganze geht so lange, bis die
code:
glutMainLoop()

beendet wurde, z.B. durch Schließen des
Fensters. Durch das DoubleBuffering wird das Zeichnen der Grafik
erheblich beschleunigt. Wer will, kann mal probieren, das Teil ohne
DoubleBuffering zu machen (erheblich langsamer).


[ - Antworten - Zitieren - Direktlink - ]

07.02.2003, 12:42 Uhr

mrbbc
Posts: 101
Nutzer
Zitat:
Original von Mad_Dog:
Das mit dem "Flackern" sollte kein Problem darstellen.


Das kann man meinem Posting entnehmen.


Zitat:
Da benutzt man dann einfach Double Buffering

Das dürfte das sein, was alle Grafikkarten schon seit der ersten "DirectX"-Karte intern beherrschen; und das ist genau das, was wir nicht brauchen können. Wir brauchen einen logischen Bildschirm, in den wir selbst schnell hinein fassen können.

Für die Grafikbeschleunigung ist das natürlich Schwachsinn. Die Grafikkarte kann ja nur in ihren eigenen Grafikspeicher grafikbeschleunigt zeichnen.

Was wir bräuchten - wenn wir das SDL-Blending von Hand programmieren - ist ein logischer Bildschirm, auf den wir direkt hinfassen können. Obwohl's wohl mit

[code]
(SDL_surface* surface, z.B. Uint8* screen)

...(surface muss zugewiesen sein)

SDL_LockSurface(surface);
screen=(Uint8*)surface->pixels;
...
<Zeichenoperationen>
...
SDL_UnlockSurface(surface);
SDL_Flip(surface);
[/quote]

schnell genug gehen sollte. Wenn das nicht reicht, muss man sich den logischen Bildschirm eben selbst programmieren.

Zitat:
Soll ich mal was zum Thema "Transparenz" hier posten?

Grundsätzlich weiss wohl jeder wie's geht; man kann aber den Algorithmus frisieren, wenn man z.B. Sonderfälle wie 50% gesondert behandelt. Mitunter ist auch z.B. >>1 schneller als /2...

[ - Antworten - Zitieren - Direktlink - ]

07.02.2003, 16:26 Uhr

Mad_Dog
Posts: 1944
Nutzer
Zitat:
Original von mrbbc:
Zitat:
Original von Mad_Dog:
Das mit dem "Flackern" sollte kein Problem darstellen.


Das kann man meinem Posting entnehmen.


Da hast Du recht. Du hast eben genau das beschrieben, was man dann
Double Buffering nennt.
Ich wollte nur nochmal kurz ein Beispiel in OpenGL bringen, um zu
zeigen, wie einfach es mit High Level Routinen geht.
Wie schnell das dann ist, steht auf einem anderen Blatt.

Zitat:
Zitat:
Da benutzt man dann einfach Double Buffering

Das dürfte das sein, was alle Grafikkarten schon seit der ersten "DirectX"-Karte intern beherrschen; und das ist genau das, was wir nicht brauchen können. Wir brauchen einen logischen Bildschirm, in den wir selbst schnell hinein fassen können.

Für die Grafikbeschleunigung ist das natürlich Schwachsinn. Die Grafikkarte kann ja nur in ihren eigenen Grafikspeicher grafikbeschleunigt zeichnen.

Was wir bräuchten - wenn wir das SDL-Blending von Hand programmieren - ist ein logischer Bildschirm, auf den wir direkt hinfassen können. Obwohl's wohl mit


Da war der Amiga seit dem ersten Modell Vorreiter (Stichwort:
Blitter). Aber es gab IMHO auch auf dem PC schon lange vor DirectX
Grafikkarten, die einen Blitter hatten.
Wieso könnt Ihr das nicht brauchen? Natürlich ist es ne Bremse, wenn
Ihr mehr Ram braucht, als die Graphikkarte hat, aber selbst meine
uralte CyberVision hat 4 MB, modernere Graphikkarten haben ja 8,16,32
oder noch mehr MB Ram. Grafikspeicher läßt sich vorallem sparen, indem
man keine rießen-Texturen für Mini-Polygone verwendet.

Zitat:
Grundsätzlich weiss wohl jeder wie's geht; man kann aber den Algorithmus frisieren, wenn man z.B. Sonderfälle wie 50% gesondert behandelt. Mitunter ist auch z.B. >>1 schneller als /2...

Nun, High Level Programmierung ist komfortabler, portabler, aber
manchmal nicht so effizient wie Low Level Programmierung. Du kannst
aber davon ausgehen, daß moderne Treibersysteme wie Warp3D oder
DirectX, auf denen ja dann wiederum die OpenGL API aufsetzt, jeweils
Subsysteme besitzen, die optimal an die darunterliegende Hardware
angepasst sind. Was hier eventuell bremst, ist eben die Kaskade von
High Level Funktionsaufrufen.

Wenn ich das richtig verstehe, wollt Ihr einfach ein konvexes Polygon
mit einer semitransparenten Textur haben, das sich dann irgendwie
bewegt?

Das vorletzte Beispiel war ja nur mit semitransparenten Polygonen,
aber ohne Textur und mit single Buffer, das Beispiel oben zeigt eben
Double Buffering...

Wie gesagt: Das Linien-Beispiel zeigt es: Die Zeichenoperationen
werden zunächst auf einem logischen Puffer gezeichnet - und der ist im
Ram der Graphikkarte, danach werden logischer und physikalischer
(=sichtbarer) Puffer ausgetauscht. Die Methode mit der glutIdleFunc()
hat auch den Vorteil, daß man sich nicht mehr um die Synchronisation
von GFX-Operationen und CPU-Stuff kümmern muß...


[ Dieser Beitrag wurde von Mad_Dog am 07.02.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

07.02.2003, 21:42 Uhr

mrbbc
Posts: 101
Nutzer
Zitat:
Original von Mad_Dog:
Aber es gab IMHO auch auf dem PC schon lange vor DirectX
Grafikkarten, die einen Blitter hatten.

Wieso könnt Ihr das nicht brauchen? Natürlich ist es ne Bremse, wenn
Ihr mehr Ram braucht, als die Graphikkarte hat, aber selbst meine
uralte CyberVision hat 4 MB...


Es ging hier nur darum, dass das transparente Blitting von SDL zu langsam ist, und der Versuch, direkt mit dem Videospeicher der Grafikkarte zu werkeln ebenso.

Foglich müsste man probieren, den logischen Bildschirm im normalen RAM an zu legen und dort zu bearbeiten, und anschließend in den physikalischen Speicher - in die Grafikkarte zu verschieben.

Grundsätzlich würde ich niemals ohne vernünftigen Grund auf die Hardwarebeschleunigung verzichten. An die kommt kein noch so toller Algorithmus ran, schon allein, weil es die CPU entlastet.

Wenn das Projekt aber schon ziemlich fortgeschritten ist, ist es aber nicht unbedingt empfehlenswert alles von SDL nach OpenGL um zu schreiben oder sogar beides zu mischen.

Programme auf plattformunabhängigen APIs verhalten sich mit einer API allein mitunter schon nicht auf jeder Plattform wie gewünscht. Die Seiteneffekte beim Mischen sind unvorhersehbar, obgleich OpenGL und SDL fürs Verstricken konzipiert wurden.

[ - Antworten - Zitieren - Direktlink - ]

08.02.2003, 00:01 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Certain:
Zitat:
Original von mrbbc:
Hmmm... da seh' ich keine bessere Lösung als das Alphablending von Hand zu Fuss zu programmieren...
Mit der SDL kann man ja direkt auf die Grafikdaten zugreifen.

Da liegt dann auch das Problem: wenn ich eine z.B. transparente Grafik auf eine andere blitten will, muss ich jeden Pixel, den ich übermalen will, vorher von der unteren Grafik einlesen. Tja, und dieser Lesevorgang ist bei Hardwaresurfaces leider ziemlich langsam unter SDL. Schneller wirds nur durch Softwaresurfaces, aber dann wird das Spiel insgesamt langsamer... ?(
Man muß nicht die Daten aus dem Grafikspeicher lesen. Der besteht ohnehin nur aus den Bilder, die Du selbst dorthin gezeichnet hast. Man kann also auch genausogut versuchen, sich zu merken, welches Objekt man an welche Stelle gezeichnet hat, um die Transparenz direkt aus den originalen Bildern zu berechnen.
Dies kann natürlich sehr komplex werden, je nachdem, wie viele Objekte man auf den Bildschirm bringt (und wie groß sie sind). Und es hängt davon ab, wie viele transparente Objekte man auf den Bildschirm bringen will. Sind es nur wenige, kann man das Tracking auf die entsprechenden Bereiche beschränken.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ Dieser Beitrag wurde von Holger am 08.02.2003 editiert. ]

[ - Antworten - Zitieren - Direktlink - ]

08.02.2003, 10:42 Uhr

Certain
Posts: 5
Nutzer
[quote]
Original von Holger:
Zitat:
Man muß nicht die Daten aus dem Grafikspeicher lesen. Der besteht ohnehin nur aus den Bilder, die Du selbst dorthin gezeichnet hast. Man kann also auch genausogut versuchen, sich zu merken, welches Objekt man an welche Stelle gezeichnet hat, um die Transparenz direkt aus den originalen Bildern zu berechnen.
Das haben wir gedanklich auch schon mal durchgespielt. Hat sich schon in der Theorie nicht als sonderlich praktikabel erwiesen.

Aber wir arbeiten daran ;)

Was das 'Mischen' von SDL und OpenGL angeht: soweit ich weiß, gibt es einige recht portable Engines, die das bis jetzt schon halbwegs erfolgreich praktiziert haben.

Ich wollte mich auch gerade mal für die wirklich umfangreiche Hilfe hier bedanken! Keine Frage, für jegliche Frage bzgl. Amiga-Coding ist man hier goldrichtig. :)


Bye,

~Certain

---
visit http://www.tukult.de

---

[ - Antworten - Zitieren - Direktlink - ]

15.02.2003, 07:21 Uhr

Andreas_Wolf
Posts: 2980
Nutzer
@ Mad_Dog:

> Leider hat Haage&Partner die StormMesa-Page herausgenommen, aber wenn
> Du dem Admin ne Mail schreibst, schickt er Dir sicher die Files (sind
> recht groß).

Die Archive sind noch online: http://www.haage-partner.de/download/3DWorld/StormMesa/

[ - Antworten - Zitieren - Direktlink - ]


-1- [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Frage bzgl. Amiga-Technologie [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.