🚀 go-pugleaf

bohn@utrurt.uucp (Hartmut Bohn) writes:

>Alle Objekte ueber das 128. hinaus werden von meinem RCS einfach
>"vergessen". Liegt das am RCS oder am TOS/GEM (Mega 2, Bj. 88,
>mit Blitter)?

Wahrscheinlich am RCS. Welches verwendest Du?

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, West Germany		(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus Brod@wue.maus.de
----------------------------------------------------------------------

In article <2309@utrurt.UUCP> bohn@utrurt.uucp (Hartmut Bohn) writes:
>Alle Objekte ueber das 128. hinaus werden von meinem RCS einfach
>"vergessen". Liegt das am RCS oder am TOS/GEM (Mega 2, Bj. 88,
>mit Blitter)?

Wahrscheinlich am Construction Set. Ich hab mal einen Dialog mit 
circa 200 Objecten gehabt. Wurde mit DR-RCS 2.1 (oder so) erstellt
und spaeter mit Kuma 2.3 weiterbearbeitet. Mit der Objektanzahl
gabs bei beiden keine Probleme. Allerdings wuerde ich dir raten mehrere
Objecte zu Gruppen zusammenzufuegen (z.B. Zeilen), da der Aufbau
auf Rechner ohne Blitter sonst quaelend langsam sein kann. 
Wenn du immer auf byte-alignment achtest, wird sich das auch bemerkbar
machen. 

Noch ein Tip: vergiss das DR-RCS. Mann kann zwar mit leben aber auf die 
Dauer koennen einige Einschraenkungen und Unbequemlichkeiten doch nerven.
Eine spaetere Konvertierung ist nicht so einfach. Man sollte sich also
moeglichst fruehzeitig entscheiden. Ich bin mit dem Kuma zur Zeit ganz
zufrieden.
cu,
				Volkmar
-- 
 Volkmar Wieners    Uucp:    ...uunet!unido!quando!wieners
   Dortmund         Eunet:   wieners@quando.quantum.de
     FRG       	    Fidonet: 2:241/5800.5      Mausnet: DO

bohn@utrurt.uucp (Hartmut Bohn) writes:

>Nochmal zu Resourcen:

>Es scheint doch eine Beschraenkung bei der Anzahl der Objekte
>in einer Resource zu geben.

>Alle Objekte ueber das 128. hinaus werden von meinem RCS einfach
>"vergessen". Liegt das am RCS oder am TOS/GEM (Mega 2, Bj. 88,
>mit Blitter)?

Das liegt *absoluter* Sicherheit an deinem RCS. Kritisch wird
es wahrscheinlich erst ab 32768 Objecten, denn man weiss beim
TOS nie, ob irgendwo aus Versehen jemand den Index als
vorzeichenbehaftet interpretiert hat. Grundsaetzlich sind aber
65536 Objekte moeglich, da die Indizierung ja rein ueber den
Index erfolgt, ueber den per mulu #24 die Adresse errechnet wird.

>Ich brauche nun dummerweise zwei Formulare mit sehr vielen
>'touchexit'-Objekten.
>Das erste soll etwa 190 - 220 'touchexit'-Icons enthalten
>(saemtliche chinesischen Radikale).
>Das zweite soll saemtliche chinesischen Silben enthalten,
>d. h. etwa 420 Textboxen (kleine Schrift) mit dem Attribut
>'touchexit'.
>Hat jemand eine Idee wie man das realisieren koennte?
>(Aufspalten in mehrere Teile geht von der Zielsetzung des
>Programms her nicht!)

Moeglich ist das ganz sicher (z.B. mit dem ganz fruehen 
Digital-Research-RCS, das noch die wenigsten Beschraenkungen
ausweisst).
Ob es sinnvoll ist, mit so vielen Objekten zu arbeiten, ist
aber eine ganz andere Frage. Alleine der Speichertechnische
Aufwand: 220+420 = 640 Icon Objekte
zu je 24 Bytes fuer Objekt-Info
      14 (?) Bytes fuer ICON-Info
   ---> 25 KB alleine fuer Objekte !!!
   zuzueglich der Graphik-Informationen, die bei ICONS auch
noch doppelt voliegen muessen, fuer Vordergrund und Hintergrund !
Der Bildaufbau fuer so ein Monstrum wuerde wahrscheinlich so um
die 30 sec benoetigen.
Zum ersten waere es schon guenstiger nur BitBlk-Grafiken zu
verwenden; der Aufwand halbiert sich dadurch.

Die sinnvollste Loesung des Problems waere jedoch, ueberhaupt
nur ein Touchexit-Objekt zu verwenden. Die Graphik brauchst Du
dann nicht mehr in vielen kleinen Einzelteilen zu entwickeln,
sondern kannst mit einem komfortablen Graphik-Editor eine
komplette grosse Block-Graphik entwerfen, die Du dann format-
los abspeicherst, und ins Programm einbinden kannst. (Bei
Unfaehigkeit des Compilers: z.B. per BASIC-Interpreter von
binaer in ASCII wandeln und einfach INCLUDEn.)

Zum Anzeigen der Graphik:
Dafuer bietet TOS die Line-A-Funktionen, hier speziell cpy_blk.
Man koennte auch GEM's copy_raster verwenden. Dabei moechte ich
auf die einschlaegige Literatur verweisen. Der Umgang mit diesen
Funktionen ist vielleicht etwas schwieriger als mit den Standard-
Objekt-Routinen vom AES, aber im Prinzip (wenn man sie mal ver-
standen und alle Fehler in der Literatur gefunden hat) sind sie
ganz einfach zu bedienen.

Als Touchexit-Objekt wird dann eine BOX genommen, und nach dem
Objekt-Aufbau die Grafik einkopiert. 

Wenn dann der User das Touchexit-Objekt angeclickt hat, muss
man nur noch die aktuelle Mausposition abfragen, und kann bei
regelmaessiger Anordnung der Objekte ganz leicht das gewuenschte
"Teil"-Objekt ueber den Objekt-Offset und die Elementhoehen
bzw. -breiten ermitteln.

Der programmtechnische Aufwand dafuer haelt sich in sehr engen
Grenzen, die Zeit- sowie Speicherplatzersparnis ist aber enorm.

Ich hoffe, dass das Dir helfen kann.

        little TOM
----
Thorsten Zoerner, Neuweiherstr.36, 8523 BD
tnzoerne@faui09.informatik.uni-erlangen.de

tnzoerne@faui09.informatik.uni-erlangen.de (Thorsten Zoerner) writes:

>Zum Anzeigen der Graphik:
>Dafuer bietet TOS die Line-A-Funktionen, hier speziell cpy_blk.

Line A ist illegal. Stattdessen verwende man vro_cpyfm und dessen
Verwandte (vr_trnfm nicht vergessen!). Das laeuft dann auch auf allen
Grafikkarten und TT-Aufloesungen.

----------------------------------------------------------------------
Claus Brod, Am Felsenkeller 2,			Things. Take. Time.
D-8772 Marktheidenfeld, Germany		 	(Piet Hein)
csbrod@medusa.informatik.uni-erlangen.de
Claus_Brod@wue.maus.de
----------------------------------------------------------------------

In article <tnzoerne.675345443@faui09>, tnzoerne@faui09.informatik.uni-erlangen.de (Thorsten Zoerner) writes:
[ ... ]
> Das liegt *absoluter* Sicherheit an deinem RCS. Kritisch wird
> es wahrscheinlich erst ab 32768 Objecten, denn man weiss beim
> TOS nie, ob irgendwo aus Versehen jemand den Index als
> vorzeichenbehaftet interpretiert hat. Grundsaetzlich sind aber
> 65536 Objekte moeglich, da die Indizierung ja rein ueber den
> Index erfolgt, ueber den per mulu #24 die Adresse errechnet wird.
[...]

Soweit mir bekannt ist, kann die Groesse der Resource-DATEI nicht
mehr als 64kB betragen, da die Offsets im Header der
Resource-Datei nur int-Werte sind. Diese Offsets dienen zum
Ansprechen der verschiedenen Teile einer Resource. (Baeume,
Alert-Boxen, free images ).

(ACHTUNG: Ich hole diese Information aus einem Assoziativspeicher
mit durchaus beschraenkter Zuverlaessigkeit und mit beschraenkter
Haftung. Die Richtigkeit kann nicht garantiert werden. Ich bin
aber fast sicher, dass mich das Netz korrigieren wird, falls obige
Information falsch ist.)

Olaf Mehlberg

--------------------------------------------------------------------
Computer sind nur Maschinen, aber bitte erzaehl meiner das nicht.
--------------------------------------------------------------------
Christian-Albrechts-Universitaet Kiel, Institut fuer Informatik
Preusserstr. 1 - 9                   , D - 2300 Kiel 1
Phone: ++49-431-5604-42              , Fax: ++49-431-566143
EMail: olm@informatik.uni-kiel.dbp.de
--------------------------------------------------------------------

In article <3998@snoopy.informatik.uni-kiel.dbp.de> olm@informatik.uni-kiel.dbp.de (Olaf Mehlberg) writes:
>Soweit mir bekannt ist, kann die Groesse der Resource-DATEI nicht
>mehr als 64kB betragen, [...]

Eine weitere Beschraenkung der Recource-Groesse besteht noch in der
maximalen Anzahl der verschachtelten Ebenen. D.h. ein Baum darf eine
maximale Verschachtlungstiefe nicht ueberschreiten. Diese ist gegeben
durch MAX_DEPTH (das setzt man bei objc_draw auch als Zeichentiefe ein)
und liegt meines Wissens bei 8 (Acht). Allerdings ist diese Beschraenkung
eher nebensaechlich, denn eine Ueberschreitung dieses Limits ist wohl eher
unwahrscheinlich...

Ciao,
     struppi


        NOTE: Please do *NOT* e-mail from out of Germany! Thank you!
------------------------------------------------------------------------------
 Stefan Rupp - RWTH Aachen |  UUCP: struppi@cip-s02.informatik.rwth-aachen.de
------------------------------------------------------------------------------