amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Datatypes und 24Bit [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2006-05-17, 22:32 h

Ralf27
Posts: 2779
User 		Mit Datatypes 24Bit-Bilder zu laden ist ja nicht so ohne weiteres möglich, bzw. hab ich da Probleme.

Ich hab z.b. IFF-ILBM24 getestet und leider wird es nicht richtig geladen. Liegt das an den Datatypes oder was muß ich machen das auch 24Bit richtig "ankommt"? Bzw. vermute ich ja das ich auch das Problem habe das ich die Bitmaps von INTERLEAVED zu "Normal" konvertieren muß und das es da Probleme geben könnte. Ich benutze aber die Systemroutinen, also nix eigenes.

Kurzum, was muß man bei Datatypes und 24Bit-Bildenr beachten, wenn man sie z.b. mit AGA benutzen möchte?
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-17, 22:55 h

thomas
Posts: 7718
User
Beim NewDTObject PDTA_DestMode,PMODE_V43 angeben. Ansonsten werden die Bilder auf 8 Bit runtergerechnet.

Gruß Thomas

--
Email: thomas-rapp@web.de
Home: thomas-rapp.homepage.t-online.de/

[ - Answer - Quote - Direct link - ]
2006-05-17, 23:33 h

MaikG
Posts: 5172
User 		Wie ich das verstanden hab kommt bei Ralf gar kein Bild mit
der ähnlichkeit zum Original an...

Sprich er hat nur AGA und bekommt ohne PDA_Dest kein Bild.

Er kann diese Modi auch nicht setzen da diese nicht in den Includes
zu Maxonbasic enthalten sind.

[ - Answer - Quote - Direct link - ]
2006-05-17, 23:55 h

Ralf27
Posts: 2779
User
Zitat:
Original von MaikG:
Wie ich das verstanden hab kommt bei Ralf gar kein Bild mit
der ähnlichkeit zum Original an...

Sprich er hat nur AGA und bekommt ohne PDA_Dest kein Bild.

Er kann diese Modi auch nicht setzen da diese nicht in den Includes
zu Maxonbasic enthalten sind.

Da hast du mich falsch verstanden. Ich bekomme ein Bild, aber es ist nicht so wie ich es mir vorstelle. Als Beispiel:

Gegeben ein Bild mit IFF-ILBM.. sagen wir mal 320*200 in 4 Bit.
Wenn ich dieses Bild lade dann läuft alles wunderbar. Wenn ich jetzt das Bild umwandle in 320*200*24, auch in IFF-ILBM(!), dann läd das Datatype das Bild und rechnet es zwar auch wieder an den Screen runter (640*256*3Bit), aber diesmal mit extremen Dither.

Hab es eben auch mit JPEG versucht, aber da ist es mir eher klar das da die Darstellung etwas anderst ist, da es ja verlustbehaftet ist.


Also mal sorum gefragt: Ist es normal das die 24Bit-Bilder schlechter aussehn als 8Bit, wenn man die 8Bit-Bilder in 24Bit umrechnet?

Und eine weitere: Läuft das ganze was ich da habe auch mit 24Bit-Bildern auf einem >8Bit-Screen richtig?
Ich vermute mal das die 24Bit-Bilder genommen werden, auf 8Bit runtergerechnet werden und dann auf 24Bit ausgegeben werden. Und da kommt wohl der neue Parameter ins Spiel denn ich dann auch setzen müßte.
Bzw. dürfte ich diesen Parameter am besten auch dann nur setzen.
--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 17.05.2006 um 23:58 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]
2006-05-17, 23:56 h

Ralf27
Posts: 2779
User
Zitat:
Original von MaikG:
Er kann diese Modi auch nicht setzen da diese nicht in den Includes
zu Maxonbasic enthalten sind.

Bei CybergraphX waren auch einige Konstanten nicht definiert und ich hab sie mir aus C-Includes rausgesucht und selbst in die MaxonBasic-Includes reingesetzt.
Also, das geht auch. :D
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-18, 01:30 h

whose
Posts: 2156
User
Zitat:
Original von Ralf27:
Also mal sorum gefragt: Ist es normal das die 24Bit-Bilder schlechter aussehn als 8Bit, wenn man die 8Bit-Bilder in 24Bit umrechnet?

Normal ist das eigentlich nicht, kann aber vorkommen, je nach dem, womit Du die Bilder auf 24Bit hochrechnen läßt.

Zitat:
Und eine weitere: Läuft das ganze was ich da habe auch mit 24Bit-Bildern auf einem >8Bit-Screen richtig?

Gute Frage... ich denke aber eher nicht, solange Du als PDTA_DestMode nicht PMODE_V43 wählst.

Zitat:
Ich vermute mal das die 24Bit-Bilder genommen werden, auf 8Bit runtergerechnet werden und dann auf 24Bit ausgegeben werden. Und da kommt wohl der neue Parameter ins Spiel denn ich dann auch setzen müßte.
Bzw. dürfte ich diesen Parameter am besten auch dann nur setzen.

Also, soweit sich mir das Ganze erschlossen hat, ist dem Datatype der Screenmode des Ziels relativ egal, solange nicht PMODE_V43 aktiv ist. Dann wird auch für 24Bit-Zielscreens mit 8Bit und palettebasiert ausgegeben.

Umgekehrt hat Dithering zur Folge.

Ich bin da bisher immer so vorgegangen, daß ich beim Öffnen des Spielscreens die Farbtiefe ermittelt habe und von da ausgehend entweder palettebasiert oder in 24Bit laden lasse.

Für Blitmasken spielt das keine so große Rolle, da diese eh in 1Bit Farbtiefe vorliegen sollten und, wenn möglich, eine extra BitMap (in der entsprechenden Farbtiefe) bekommen sollten. Das reduziert die Gefahr einer möglichen Verwirrung mit dem Ausgangsformat ;)

Grüße

--
---

:boing: µA1 PPC 750GX-800
:boing: A4000 PPC 604e-233


[ Dieser Beitrag wurde von whose am 18.05.2006 um 01:44 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]
2006-05-18, 09:48 h

MaikG
Posts: 5172
User 		>Gegeben ein Bild mit IFF-ILBM.. sagen wir mal 320*200 in 4 Bit.
>Wenn ich dieses Bild lade dann läuft alles wunderbar. Wenn ich
>jetzt das Bild umwandle in 320*200*24, auch in IFF-ILBM(!), dann
>läd das Datatype das Bild und rechnet es zwar auch wieder an den
>Screen runter (640*256*3Bit), aber diesmal mit extremen Dither.

Schalte Dithern doch aus.


CONST PDTA_DestMode& = &h800010FB&

0 - V42
1 - V43

[ - Answer - Quote - Direct link - ]
2006-05-18, 12:01 h

Holger
Posts: 8116
User
Zitat:
Original von MaikG:
Schalte Dithern doch aus.


CONST PDTA_DestMode& = &h800010FB&

0 - V42
1 - V43

Solange er in eine BitMap <24Bit blittet, die dann auf den Bildschirm kommt, kann er das nicht verhindern.

mfg

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

[ - Answer - Quote - Direct link - ]
2006-05-18, 13:16 h

bubblebobble
Posts: 707
User 		Oder du machst das ganze in Amiblitz, dort kannst du den Grad des Ditherns einstellen, von 0-100%. Sehr nützlich z.B. für GUI Elemente, wo man meistens kein Dithern haben möchte:

image_load{imageID,file,trgb,toleranz,dithermode,ditheramount}
z.B.:
image_load{1,"mypic.png",$FF00FF,1,#DITHERMODE_FS,50}

Oder du implementierst das analog in Maxon, indem du die guigfx.library benutzt, anstelle der Datatypes direkt.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-18, 21:40 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:
Oder du machst das ganze in Amiblitz, dort kannst du den Grad des Ditherns einstellen, von 0-100%. Sehr nützlich z.B. für GUI Elemente, wo man meistens kein Dithern haben möchte:
Leider kann ich kein AmiBlitz benutzen, weil ich hier keine Grafikkarte habe. Leider erwartet AmiBlitz eine CybergraphX-Installation. Aber CybergraphX für AGA extra für AmiBlitz?
Zitat:
image_load{imageID,file,trgb,toleranz,dithermode,ditheramount}
z.B.:
image_load{1,"mypic.png",$FF00FF,1,#DITHERMODE_FS,50}

Oder du implementierst das analog in Maxon, indem du die guigfx.library benutzt, anstelle der Datatypes direkt.
Das liest sich auch wieder recht interesant. Daran hab ich auch noch nicht gedacht.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-19, 11:07 h

bubblebobble
Posts: 707
User 		Achso, stimmt, du nutzt ja AGA. Frage doch mal Bernd, es gibt eigentlich keinen Grund warum Amiblitz CGX braucht, ausser einer erweiterung von mir, aber Amiblitz kann auch ohne diese Erweiterung kompiliert werden.
Aber möglicherweise brauch auch guigfx bereits CGX. Die CGX Erweiterungen sind halt mittlerweile quasi Standard, so wie AHI für Audio.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-19, 12:09 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:
Aber möglicherweise brauch auch guigfx bereits CGX. Die CGX Erweiterungen sind halt mittlerweile quasi Standard, so wie AHI für Audio.

GuiGFX braucht kein CGX, ich benutze es ja auch hier mit AGA. AHI benutze ich hier auch, RTGMaster läuft auch hier mit AGA.

Aber das ein Compiler CGX vorraussetzt... :dance3:
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-19, 13:42 h

bubblebobble
Posts: 707
User 		Der Texteditor braucht vermutlich CGX. Der Compiler nicht.
Evtl. liegt es aber auch an was anderem.

Mit AHI meinte ich, das AHI genauso wie CGX eine OS API Erweiterung
des OS darstellt. AHI hast du installiert, weil sonst z.B. AmiAmp usw. nicht funktionieren würden. Manche Programme brauchen aber auch CGX, nur hauptsächlich für 24bit, deshalb fällt dir das nicht auf, es gibt aber auch noch andere Funktionen in CGX die nützlich sind.

Möglicherweise brauchen auch manche Datatypes CGX, wenn du mit 24bit Bildern hantierst.

Willst du nicht mal auf Graka umsteigen ? Mit einer höheren Auflösung steigt die Anzahl der Zeilen von Sourcecode, die man überblicken kann, und damit auch die Qualität und Geschwindigkeit der Programmierung. Ich hatte oft den Effekt, dass ich, wenn ich auf eine höhere Auflösung umgestiegen bin, auf einmal offensichliche Bugs gefunde habe, und vorher wie blind war.

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-19, 15:27 h

Holger
Posts: 8116
User
Zitat:
Original von bubblebobble:
Mit einer höheren Auflösung steigt die Anzahl der Zeilen von Sourcecode, die man überblicken kann, und damit auch die Qualität und Geschwindigkeit der Programmierung.

Da gibt's aber auch die Gegentheorie: „Ein gut modularisiertes Programm besteht aus Funktionen, von denen jede für sich auf eine Bildschirmseite paßt“.
Dieses Axiom dadurch zu hintergehen, daß man 2000x1000 Auflösung auf 30" Bildschirm benutzt, verbessert nicht unbedingt die Qualität der Software.

Übertrieben gesagt, natürlich;
mit Basic ist das eh so eine Sache...

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

[ - Answer - Quote - Direct link - ]
2006-05-19, 15:28 h

gni
Posts: 1106
User
Zitat:
bubblebobble:
Möglicherweise brauchen auch manche Datatypes CGX, wenn du mit 24bit Bildern hantierst.
CGX hat mit 24-Bit für PicDTs nichts zu tun. Mit CGX kommt ein PicDT gar nicht in Berührung. Ein PicDT verwendet das V43 API wenn echtes 24Bit benutzt werden soll und um den Rest hat sich die Superklasse zu kümmern ;-)

[ - Answer - Quote - Direct link - ]
2006-05-19, 16:03 h

bubblebobble
Posts: 707
User 		@Holger

Das ist schon richtig, aber bei AGA hast du eine Auflösung von 256.
Da bekommst du maximal gerade mal 32 Zeilen (PAL) oder 25 Zeilen (NTSC) drauf gequetscht bei einer 8x8 Font.
Wenn man noch ein bisschen Screen Titel und GUI abzieht ist das wirklich nicht viele.
Manche Funktionen sind einfach größer, z.B. FFT.
Zu viele Zeilen ist natürlich auch nicht gut, aber ich denke das otpimum erreicht man irgendwo bei einer Auflösung ab 1024 Höhe und einer relativ kleinen Font (also 8-12 pixel hoch).

--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-19, 17:42 h

Holger
Posts: 8116
User
Zitat:
Original von bubblebobble:
Das ist schon richtig, aber bei AGA hast du eine Auflösung von 256.
Da bekommst du maximal gerade mal 32 Zeilen (PAL) oder 25 Zeilen (NTSC) drauf gequetscht bei einer 8x8 Font.
Na ja, VGA 480 oder 50Hz 512 gehen durchaus auch, mit TFT und etwas Glück sogar noch ein bisserl mehr (ohne sich die Augen zu verderben).

Aber eben ohne Augenschmerzen länger draufschauen zu können, ist wirklich Gold wert. Also höhere Bildfrequenz oder Auflösung (und größerer Font) verbessern die Produktivität ungemein. Insofern hast Du natürlich recht, Grafikkarte rentiert sich für Entwickler. <blasphemie>PC mit cross-compiler noch viel mehr</blasphemie>.

mfg

PS: hab mal kurz nachgeschaut, bei mir sind's derzeit 40 Zeilen aber dafür die ca. 80 Zeichen in der Breite und vor allem das Ganze mit deutlich besserem Font als 8x8, flimmerfrei und diversen Werkzeugen um den Editor drumherum...
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]
2006-05-19, 17:51 h

bubblebobble
Posts: 707
User 		Hm, das wäre mir zu wenig. Mit Amiblitz habe ich 120 Zeilen, mit Topaz 8 font, im TuiTED (für C) etwa 60. Ist vielleicht ein bisschen zu viel, gebe ich zu. Aber 60-80 Zeilen denke ich solltens schon sein, zumindest für mich. Dann muss man funktionen auch nicht unnötig zerhacken, wenn sie straight-foreward sind.


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-19, 21:27 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:

Willst du nicht mal auf Graka umsteigen ? Mit einer höheren Auflösung steigt die Anzahl der Zeilen von Sourcecode, die man überblicken kann, und damit auch die Qualität und Geschwindigkeit der Programmierung. Ich hatte oft den Effekt, dass ich, wenn ich auf eine höhere Auflösung umgestiegen bin, auf einmal offensichliche Bugs gefunde habe, und vorher wie blind war.

Ich hab hier auch einen A1200T mit BPPC und BVision. Leider zur Zeit defekt. Und auch auf diesem Rechner hatte ich damals Probleme mit AmiBlitz.

Also, ich habe/hatte hier beides und rate mal wo ich lieber programmiert habe? :)

Kein Witz, aber der große war bei mir in Sachen programmieren nur zum testen da. Es hat mir einfach kaum Spaß gemacht bei 1024*768 auf einem 19"-Moni zu programmieren.

Außerdem wird man blind bei zu vielen Zeilen. Mir ist es jedenfalls so ergangen.
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-19, 21:30 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:
@Holger

Das ist schon richtig, aber bei AGA hast du eine Auflösung von 256.
Da bekommst du maximal gerade mal 32 Zeilen (PAL) oder 25 Zeilen (NTSC) drauf gequetscht bei einer 8x8 Font.
Wenn man noch ein bisschen Screen Titel und GUI abzieht ist das wirklich nicht viele.
Manche Funktionen sind einfach größer, z.B. FFT.
Zu viele Zeilen ist natürlich auch nicht gut, aber ich denke das otpimum erreicht man irgendwo bei einer Auflösung ab 1024 Höhe und einer relativ kleinen Font (also 8-12 pixel hoch).

Das ist eingentlich Käse. Bei PAL und NTSC bieten sich die Overscanauflösungen geradezu an. Wenn man dann denn Monitor etwas von der Auflösung her runterdreht und PAL auf Overscan bringt, dann hat man eine höhere Auflösung bei der gleichen Bildfrequenz.

Bei meinem kleinen hab ich so die Auflösung bei PAL etwas aufgedreht und hab nun 33Zeilen bei der Darstellung. Und mir reicht dies eigentlich aus.

Aber jedem so wie es ihm Spaß macht. :)
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-19, 21:32 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:
Hm, das wäre mir zu wenig. Mit Amiblitz habe ich 120 Zeilen, mit Topaz 8 font, im TuiTED (für C) etwa 60. Ist vielleicht ein bisschen zu viel, gebe ich zu. Aber 60-80 Zeilen denke ich solltens schon sein, zumindest für mich. Dann muss man funktionen auch nicht unnötig zerhacken, wenn sie straight-foreward sind.

Mit AGA wären 120Zeilen auch möglich, aber das wäre auf dem 14"-Moni eine Suche mit der Lupe. :)


Aber selbst auf einem 19" mit Grafikkarte wären mir 120Zeilen eindeutig viel zu viel.

Aber wie schon geschrieben, jedem so wie er es mag. :D
--
http://www.alternativercomputerclub.de.vu

[ - Answer - Quote - Direct link - ]
2006-05-20, 00:51 h

NoImag
Posts: 1050
User
Zitat:
Original von bubblebobble:
Zu viele Zeilen ist natürlich auch nicht gut, aber ich denke das otpimum erreicht man irgendwo bei einer Auflösung ab 1024 Höhe und einer relativ kleinen Font (also 8-12 pixel hoch).

Mir ist das viel zu viel. Ich habe meinen Editor extra nur auf 1024x768 (mit Topaz 11, 17"-Monitor) laufen, weil mir die Schrift auf meiner Standard-Auflösung (1152x852) zu klein ist. Ich könnte zwar eine größere Schrift einstellen, aber damit würde ich zum einen nur die höhere Auflösung wieder kompensieren und zum anderen empfinde ich Topaz als besser lesbar als die anderen Fonts, die ich so habe. Lesbarkeit der Schrift geht mir beim Programmieren über alles andere. Welchen Font benutzt du?

Tschüß


[ - Answer - Quote - Direct link - ]
2006-05-20, 15:29 h

bubblebobble
Posts: 707
User 		Es ist wirklich müßig, sich über die Anzahl der Zeilen zu steiten.

Allerdings gehen 120 Zeilen auf AGA nicht. Oder willst du eine Font mit 4 Pixel Höhe, das kann ja kein Mensch lesen ?

Ich benutze für AB2 meistens Topaz/8. Für C benutze ich Vera Sans/15 (mit AfA) oder früher Helvetica/13 (ohne AfA), auf einem 19" TFT bei 1280x1024. Das ist für mich optimal, muss für andere sicher nicht so sein.

Bei C Programmiere ich aber auch eher im Basic Stil, d.h. dichter gedrängt. Bei C wird oft sehr inflationär mit den Zeilen umgegangen, gerade da bräuchte man doch eigentlich mehr Zeilen auf dem Bildschirm.

zB.
code:
void test() 
{
   myfunc(param1,
          param2,
          param3);

   return (0);
}
würde ich schreiben (in der Hälfte der Zeilen):
code:
void test() {
  myfunc(param1,param2,param3);
  return (0);
}


--
Thilo Köhler, Author von:
HD-Rec, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, TKUnpacker
Homepage: http://www.hd-rec.de


[ - Answer - Quote - Direct link - ]
2006-05-20, 21:39 h

Ralf27
Posts: 2779
User
Zitat:
Original von bubblebobble:
Es ist wirklich müßig, sich über die Anzahl der Zeilen zu steiten.

Allerdings gehen 120 Zeilen auf AGA nicht. Oder willst du eine Font mit 4 Pixel Höhe, das kann ja kein Mensch lesen ?

Ist es wirklich. Denn ich würde niemals 120Zeilen benutzen, auch auf einem System mit Grafikkarte, da es eigentlich für mich unübersichtlich ist. Aber jedem das seine :D

Achja, für Hardcoreleute: 120Zeilen geht auch auf AGA mit snapshot und da geht sogar noch mehr: Z.b. auf 1024*768*8 mit snapshot=128Zeilen, bzw. mit Topaz8=96 Zeilen. (ok, minus Titelleiste)
Nur das würde bestimmt keiner benutzen.

Edit:
Oder z.b. MULITSCAN: Producitvity Interlace: 640*960: -> snapshot=160 Zeilen, Topaz8=120

Ha! :D I-)

Ok, jetzt aber genug von den Extremen. Ich finde 30-40 Zeilen sind genug für mich. Was andere benutzen müssen sie selbst wissen. Bzw. konnte ich auch schon Grafikkarten testen und hab auch da die Zeilenanzahl nicht erhöht.


--
http://www.alternativercomputerclub.de.vu

[ Dieser Beitrag wurde von Ralf27 am 20.05.2006 um 21:46 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]
2006-05-21, 11:33 h

Holger
Posts: 8116
User
Zitat:
Original von bubblebobble:
Bei C wird oft sehr inflationär mit den Zeilen umgegangen, gerade da bräuchte man doch eigentlich mehr Zeilen auf dem Bildschirm.

zB.
code:
void test() 
{
   myfunc(param1,
          param2,
          param3);

   return (0);
}
Das ist kein normaler C-Stil. Parameter werden üblicherweise genauso in eine Zeile geschrieben, wie in anderen Programmiersprachen auch. Du hast einfach die andere Eigenheit viele C-Programmierer übersehen.
code:
void test()
                        {
                                    myfunc(param1,
                                           param2,
                                           param3);

                                    return (0);
                        }
So sieht ein normales C-Programm aus. Die Parameter sind nur deshalb untereinander geschrieben, weil der rechte Rand erreicht wurde.

Zitat:
würde ich schreiben (in der Hälfte der Zeilen):
code:
void test() {
  myfunc(param1,param2,param3);
  return (0);
}

Das entspricht in etwa Suns Styleguide für Java. Wobei die meisten Programmierer dann doch unter void test() { eine Leerzeile einfügen, damit es lesbarer wird.

Weil man dann genausogut statt der Leerzeile die Klammer in eine eigene Zeile schreiben kann, und ich lieber öffnende und zugehörige schließende Klammer auf derselben Höhe habe, schreib ich das dann doch so:
code:
void test()
{
  myfunc(param1, param2, param3);
  return 0;
}

(Aber man kann auch Ewigkeiten über Codestyle diskutieren, während die eigentliche Software liegen bleibt...)

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

[ - Answer - Quote - Direct link - ]

-1- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Datatypes und 24Bit [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.