| Szerző |
Üzenet |
dekanyz
Tag
|
# Elküldve: 2014. Máj. 07. 13:53
Ujabb GL-es kerdes:
http://www.opengl.org/archives/resources/code/samples/glut_examples/examples/bitfont. c
Miert nem latszik semmi? A bitmap font-ok megjelenitese mukodik MOS alatt?
(A nemfordulo reszek kikommentezve)
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 07. 15:01 - Szerkesztve: charlie
@dekanyz:
Kéne az a verzió, ami le is fordul. :)
Kiero szerint kéne mennie a bitmap fontoknak, menü support ismerten nincs, a kódot eltette és "majd megnézi".
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 07. 19:47
A main()-ben a menus reszt kikommentezve fordul az... ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 08. 00:08
@dekanyz:
A fenti bitfont.c egy TinyGL bug miatt nem megy R300-on. (R200-on elvileg működik.) A következő MorphOS verzióban a hiba javítva lesz.
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 08. 06:25
Azaz par napon belul? ;)
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 08. 11:24 - Szerkesztve: charlie
"Még két hét" és már jön is! :P
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 13. 17:23
Ugy tunik, mintha a glutFullScreen() se mukodne...
Vagy, ez is csak az R300 jellegzetessege?
Megj.: A Hurrican-nak sikerult nalam a multkor fullscreen-re kapcsolnia!
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 13. 17:36
A glutFullScreenben van valami workaround, hogyha az adott felbontast nem birja bevaltani az adott gepen, akkor marad windowed modban! Ez meg mindig jobb mint a korabbi megoldas amikor netto szetfagyott. :P Ezt onnet tudom h. a bugot en reportoltam.
A Hurrican szerintem nativ vagy SDL-es es nem GLUT.
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 14. 14:02
Nah, kovetkezo kerdes:
Hogy lehet kurzort elrejteni?
Egy GL-es alkalmazasrol van szo.
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Máj. 14. 14:11
Natív vagy glut? Van glutSetCursor() de nemtudom, hogy működik-e... Van egy rakás flagje, közte a GLUT_CURSOR_NONE.
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 14. 14:37
OK.. megnezem, koszonom!
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 15. 06:23 - Szerkesztve: dekanyz
Nincs benne a MOS-os implementacioban glutSetCursor().
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 26. 19:59
Kovetkezo kerdes:
#include <GL/glut.h>
#include <stdlib.h>
#include <stdio.h>
void keyboardHandle(unsigned char key, int x, int y)
{
printf("New keyboard event...\n");
switch (key)
{
case 'q':
case 27:
glutDestroyWindow(0);
exit(0);
break;
default:
printf("Unhandled keyboard event happened...\n");
}
}
int main(int argc, char **argv)
{
glutInit(&argc, argv);
glutInitDisplayMode(GLUT_DEPTH | GLUT_DOUBLE | GLUT_RGBA);
glutInitWindowSize(100, 100);
glutCreateWindow("Prism: The Picture Viewer");
glutKeyboardFunc(keyboardHandle);
glutMainLoop();
return 0;
}
Az a problema, hogy q-ra/ESC-re kilep a program, de az ablak nem zarodik be.
|
anchor
Tag
|
# Elküldve: 2014. Máj. 26. 20:31
dekanyz:
a tippem a következő:
glutCreateWindow() visszatérési értékét tárold el, és azzal hívd meg a glutDestroyWindow()-ot.
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 27. 06:41
anchor:
En is gondoltam valami ilyesmire is...
Mivel egy ablak van a 0 se tunik annyira rossznak.
Amugy, az osszes glut-os peldaban meg glutDestroyWindow() sincs, csak exit(0).
Ha az ablakot bezaro x-re (gomb a bal felso sarokban) kattintok, akkor jol bezarodik az alkalmazas.
Azert megprobalom ugy is, ahogy javallottad...
|
dekanyz
Tag
|
# Elküldve: 2014. Máj. 27. 09:27
Kiprobaltam... tenyleg a windowID eltarolasa volt a megoldas! :)
|
dekanyz
Tag
|
# Elküldve: 2014. Jún. 24. 13:42 - Szerkesztve: dekanyz
Ket kerdes:
1: A glutPassiveMotionFunc() implementacioja nincs veletlen tervbe veve MOS-on? Hasznos lenne!
2: A Command gomb kezelheto valahogy (Meg mindig GLUT-rol van szo)?
|
AliveMOon
Tag
|
# Elküldve: 2014. Júl. 22. 21:22 - Szerkesztve: alivemoon
Lenne egy kérdésem:
Létre hozok egy project icon-t, abban megadom a default tool-ban a saját progim nevét, ami valahol mondjuk a C: könyvtárban van.
Hogyan kell kinyerni, honnan és ki melyik icon-ról hívta?
Ha jól sejtem a GetDiskObject -nek én mondom meg melyik ikont töltse be?
|
Chain-Q
Divatamigás
|
# Elküldve: 2014. Júl. 22. 21:34 - Szerkesztve: charlie
Szerintem a WBStartup message környékén érdemes turkálni.
Workbench arguments are passed as an array of WBArg structures in the sm_ArgList field of WBStartup. The first WBArg in the list is always the tool itself. If multiple icons have been selected when a tool is activated, the selected icons are passed to the tool as additional WBArgs. If the tool was derived from a default tool, the project will be the second WBArg. If extended select was used, arguments other than the tool are passed in the order of selection; the first icon selected will be first (after the tool), and so on.
Idézet innen.
|
AliveMOon
Tag
|
# Elküldve: 2014. Júl. 22. 22:07 - Szerkesztve: alivemoon
Ok!
Kösz!
Müxik!
Valahogy így néz ki:
.........sub.l a1,a1 ; Zero - Find current task
.........CALLEXEC FindTask
.........move.l d0,_thisTask
.........move.l d0,a4
.........tst.l pr_CLI(a4)
.........bne.s .fromCLI
.........move.b #TRUE,b_WB
.........lea pr_MsgPort(a4),a0
.........CALLEXEC WaitPort
.........lea pr_MsgPort(a4),a0
.........CALLEXEC GetMsg
.........move.l d0,p_returnMsg
.........move.l d0,a0
.........cmp.l #2,sm_NumArgs(a0)
.........bne .fromCLI
.........move.l sm_ArgList(a0),a0
.........tst.l a0
.........beq .fromCLI
.........add.l #wa_SIZEOF,a0
.........move.l wa_Name(a0),p_project
.........move.l wa_Lock(a0),p_project+4
.........bra .fromWB
.fromCLI:
.........move.l pr_CurrentDir(a4),p_project+4
.........;move.l pr_HomeDir(a4),p_project+4
.fromWB:
|
mc68k
Tag
|
# Elküldve: 2015. Jan. 13. 15:08 - Szerkesztve: mc68k
Egy kérdés, amire eddig nem találtam részletes választ:
Annak idején, amikor elkészítették a Picasso drivert (az elődje a Domino kártya + driver volt, http://amiga.resource.cx/exp/domino), az a mese járta, hogy az AmigaOS nem támogatja az RTG grafikát.
A Domino és Picasso drivereknek OS 2+ kell. Ezek beépülnek a monitor driverek közé.
Kérdezem a szakértőket (Charlie! :) ), hogy lehetne-e kapni egy áttekintést ennek a működési módjáról, ill. hogy hogyan épül be az OS-be, ha nincs RTG grafika támogatva?
Egy régi interjúban az áll, hogy patch-elték a teljes graphics.library-t. 4-5 évvel ezelőtt el is kezdtem resource-olni a driver-t (a file neve nyilván Sontowski volt, a készítője után), de eléggé összetettnek tűnt.
A monitor driverek (Pal, NTSC, Multiscan stb.) elméletileg csak az időzítési információkat tartalmazzák.
Ezeknek a dolgoknak a pontos és részletes (tömören összefoglalt) működési módja érdekelne.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Jan. 13. 16:35 - Szerkesztve: charlie
Amennyire tudom a monitor driverek ugyanúgy executable-ek bár a "gyári" monitor driverekben szinte semmi sincs, csak a már általad is említett paramétertábla a módokhoz. Csak tipp, de gondolom a módtábla csak egy további IFF chunk a monitordriverben? Amit amúgy a sima exe betöltő átugrik. Szerk: bár az is lehet h. simán csak valami táblázat a kódban. Fogalmam sincs.
Emiatt - mivel executable-ekről van szó - ha futtatásra kerül egy ilyen RTG driver, akkor inicializálni tudja a komplett RTG alrendszert, ami igen, nagyrészt a graphics.library rommá-patkolásáról szól, valamint a hívások átirányításáról az rtg.library-ra ill. a cybergraphics.library-ra, RTG rendszertől függően. Ezek a library-k aztán definiálnak egy saját driver API-t, amire a mindenféle tényleges grafikuskártya driverek épülnek. Ezen kívül mindkettő további funkciókat is ellát, pl. mindkettőnek van/volt a gyári layers.library-nál gyorsabb, saját layers megoldása, valamint további extra függvényeket is defináltak pl. a chunky ill. a truecolor grafika egyszerűbb kezeléséhez.
A fentiek miatt saját RTG driverek írásához az RTG rendszerek saját driver SDK-ja szükséges, ami nem publikus, ráadásul a CGFX és a P96 driverek nem is kompatibilisek egymással. Azért gondolom kézen-közön is beszerezhető (nekem *nincs* meg, csak a félreértések elkerülése végett), pl. az Elbox sikeresen lőtt egy P96 SDK-t valahol és fejleszettek saját szakállra Radeon drivert, ami miatt a P96 eredeti írói nem igazán örültek... De amennyire tudom ők már nem is aktívak amigán, szóval az OS4 megkapta a P96-ot de amennyire tudom a 4.1FE-ben már elkezdték lecserélni ill. a graphics.library-be integrálni is. Bár kijött nemrég egy mindenféle random patchelt 68k verzió is az rtg.libraryből, szóval passz...
A CGFX-et mai napig karbantartja a készítője, a MorphOS fejlesztő Frank Mariak, a CGFX v4 megvehető 68k-ra, a v5 pedig a MorphOS része.
Röviden - ezt nem fogod házon belül megoldani SDK nélkül. Hacsak nem akarsz egy komplett új RTG rendszert írni. Persze egy meglévő drivert lehetne reverse-engineerelni és belepatkolni valami másnak a támogatását, de én nem akarnék elkezdeni ezzel szopni...
|
mc68k
Tag
|
# Elküldve: 2015. Aug. 28. 09:30 - Szerkesztve: mc68k
Nem akarok új topicot nyitni, így ide írom, hátha van itt egy hardware / demo coder, aki kapásból ad választ a kérdésemre. :)
Packed 8x8-as font-ból kellene kivenni a 2. Byte-on elhelyezkedő karaktert:
ABCDEFGH.....
Ebben az esetben legyen ez a B karakter. Ezt kellene maszkolni és shiftelni BALRA, egy lépésben, blitterrel, úgy, hogy a blitter operáció magassága 8 bit legyen.
A probléma: a blitter csak JOBBRA tud shiftelni (ami forgatás valójában), így az egész image egy pixellel lejjebb csúszik és elveszik az alsó sor, ha 8 pixel magasságot másolok.
Van erre megoldás, hogy 8x8-as blitterművelettel kivitelezhető legyen (ami 16x8-as valójában, de maszkolva van) és ne pedig 9 pixel magassággal kelljen dolgozni?
A másik dolog, ha nem kell összemásolni a háttérrel a char-t, akkor CPU-val ez az egész művelet gyorsabb, mint blitterrel (8x move.b) és meg van oldva a háttér törlése is egyben (szövegkiíró rutin lesz). Azért gyorsabb, mert mire beállítom a blitter regisztereket, több utasítást kell használni, mint amennyivel át bírom másolni a 8x8-as karakter 8 Byte-ját.
Én vagyok a láma és nem látom a jó megoldást, vagy valóban nincs más megoldás?
|
mc68k
Tag
|
# Elküldve: 2015. Aug. 28. 11:57 - Szerkesztve: mc68k
Közben meg is lett a válasz: blitter descending mode
http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node0120.html
Működik is a dolog, le van tesztelve.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Aug. 28. 12:04 - Szerkesztve: charlie
En ezt ugy oldottam meg (bar az OS szinten volt, BltTemplate()), hogy 16bitre alignoltam a fontot. Tehat pixelsoronkent van 1 ures byte. Ez volt a legegyszerubb, es valszeg a leggyorsabb is. Ezzel 2K helyett 4K lesz a font (1bpl, 256 karakter eseten), ha jol szamolom, de nem kell shiftelni es maszkolni a Blitterrel. Ha helyszukeben vagy a lemezen, akkor eleg a fontot initkor "szetpakolni" a RAM-ba egy 3 soros rutinnal. Ezzel egyebkent a Blitter setup es mukodes is gyorsul. Egyebkent siman elofordulhat, hogy sok kicsi muvelet lassabb Blitterrel a setup miatt mint CPU-val. Ez altalanos problema mai napig parhuzamos rendszerekben, hogy mi a gyorsabb, helyben megoldani a kerdest, vagy offloadolni valahova... Mellesleg, 7Mhz-n gyorsabb vagy 50-en? :)))
Amugy, nem astam bele magam, de: http://amigadev.elowar.com/read/ADCD_2.1/Hardware_Manual_guide/node011F.html
Ez hadoval valamit olyan tipusu font maszkolasrol, ami neked kell.
Szerk: Nabazz. :) Post kozben nehez eszrevenni az uj hozzaszolast.
|
mc68k
Tag
|
# Elküldve: 2015. Aug. 28. 12:09 - Szerkesztve: mc68k
A word aligned fontset-en én is gondolkoztam, de mondván, hogy az Amiga fontok (topaz stb). is packed formában vannak, így mégsem ezt az utat választottam. Ha ők meg tudják csinálni, akkor én is, hisz akkor lehetséges. Viszont az overhead nem mindegy, hogy mekkora. A graphics.library mindenre gondol, az overhead iszonyatosan sok, a speed meg iszonyatosan lassú.
Ami a fájó, hogy még 7 MHz-en is gyorsabb a font kiírása CPU-val, mint blitterrel, mert annyi regisztert kell beállítani (és az értékeket kiszámolni stb.), hogy addig a CPU símán átmásolja a lassú Chip RAM-ba a 8x8-as karaktert. Tanulságos történet. :)
|
mc68k
Tag
|
# Elküldve: 2015. Aug. 29. 20:17 - Szerkesztve: mc68k
Napi találós kérdés Charlie számára (ill. bárkinek, aki meg tudja válaszolni). :)
Miért jó az, hogy a 68000-es interrupt esetén az autovector számát az interruptot kérő perifériától kapja, buszcikluson keresztül és nem pedig automatikusan a megfelelő autovector alapján hajt végre ugrást (int1 -> $64, int2->$68 stb.)?
Vagyis ez úgy jön ki, hogy van 7 CPU interrupt level és ha pl. a 2-es interruptot kéri egy periféria, akkor az automatikusan nem a $68-as címen levő címre ugrik indirekt módon, hanem a CPU megvárja, hogy a periféria közölje az interrupt vector címét (4-gyel kell szorozni a CPU-nak belsőleg, vagyis << 2, mivel az egyes interrupt $18-as, a kettes $19 stb. formában van jelezve a CPU számára). Így gyakorlatilag a 2-es IRQ ugorhat bármilyen címre ami az 1-es és a 7-es vector-ban definiálva van.
Ez a 68000 lehetősége. Amigán ez fixen van megoldva: nem a perifériától kapja az indexet, hanem hardcoded a ROM-ban ($fffff0 címtől kezdődően helyezkednek el a fix táblapointerek: $18, $19 stb.). Így egyértelmű, hogy a 2-es interrupt mindig a $68-as vector alapján hajt végre indirekt ugrást.
Három órán át kerestem a hibát, hogy miért ugrik mindig 0-ra, pedig jó cím szerepel a $68-ban? A M68000 UM leírja a hardveres megvalósítását a dolognak, ami világos is, de szerintem ez túlzott flexibilitás (dupla indirekció). Lehet, hogy a 8 bites perifériák miatt volt erre szükség, de még egyelőre nem teljesen világos az oka.
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Aug. 30. 02:42 - Szerkesztve: charlie
@m68k:
Namost, előrebocsátom, hogy tökre nem értek hozzá, de szerintem:
Miért jó az, hogy a 68000-es interrupt esetén az autovector számát az interruptot kérő perifériától kapja, buszcikluson keresztül és nem pedig automatikusan a megfelelő autovector alapján hajt végre ugrást (int1 -> $64, int2->$68 stb.)?
Amennyire sikerült utánaásnom, ez a kérdés és az alapját képező feltevés, hibás. Mivel, 68k-n kétféle interrupt van:
A., normál
B., autovectored
A normál interrupt esetén a device megmondja a 68k-nak hogy hova ugorjon, és ez az interrupt *NEM* megy keresztül az autovector interrupt táblán. A Motorola user manual az 64-255 ($100-$3FF) vektorokat hívja User interrupt vector-nak, a megfelelő offsetet IACK ciklusban a D7-0 vonalakról veszi a CPU:
"The interrupt acknowledge cycle places the level of the interrupt being acknowledged on address bits A3–A1 and drives all other address lines high. The interrupt acknowledge cycle reads a vector number when the interrupting device places a vector number on the data bus and asserts DTACK to acknowledge the cycle.
(...)
Alternately, the interrupt acknowledge cycle can be autovectored. The interrupt acknowledge cycle is the same, except the interrupting device asserts VPA instead of DTACK. For an autovectored interrupt, the vector number used is $18 plus the interrupt level. This is generated internally by the microprocessor when VPA (or AVEC) is asserted on an interrupt acknowledge cycle. DTACK and VPA (AVEC) should never be simultaneously asserted." (Motorola 68000 User Manual, 5-10 oldal)
Nem tudom a normál mód van-e egyáltalán használva Amigán. Gyanús, hogy az OS és a platform flexibilitásába nem nagyon fér be az, hogy fix interrupt vektorokat akarjanak maguknak eszközök, ezért Amigán az interrupt multiplexelés az OS oldalán van, szoftveresen. Ha jól értem. :)
(Szerk: na igazam volt és tévedtem - Amigán is vannak normál interruptok - Zorro III-as kártyák esetén. Quick Interruptsnak hívja őket a manual és csak a 3.0+ exec.library tartalmaz függvényeket a kezeléséhez. Gyakorlatilag az exectől kell kérned egy interrupt vectort, amit aztán beadhatsz a kártyádnak, hogy ezt hívd paraszt... De a kártyádnak enélkül is működnie kell. Főleg mert a korai execek ugye nem ismerik ezt... Ill. nem ZIII hardveren a szükséges HW support is hiányzik, szóval bukó.)
De pl. Atari ST-n használták, az MFP (Multifunctional Peripherial Controller) csatlakoztatásához, ami az $100-tól kezdődő interrupt vektorokat használta magának. Ide hookolták fel később az STE Blitterét is, pl.
Ha az interruptot előidéző eszköz nem tudja megadni hogy melyik interrupt vector akarja éppen meghívni, akkor a processzor Autovector Interrupt módba lép, és az IPL-ből generál magának egy autovector offsetet, bár annak a 68k UM-ben sehol sem találtam nyomát, hogy a processzor bármit is kotorna a címterület tetején, de ha te azt mondod, akkor elhiszem, meg valami Amiga manual amit kigugliztam is említi.
Namost, hogy ezek mellett miért ugrik 0-ra a rutinod azt persze továbbra sem tudom, de elég gyanús, hogy Amigán ha fut az OS, akkor nem akarod csak úgy felülirogatni az interrupt és exception vektorokat, lévén mint már említve volt, a multiplexelés az OS oldalán van... Mivel nem ismerem a kontextust, hogy éppen mit debugolsz, ezért innentől passz. Csak mivel az alapfeltevésben is voltak hibák, gondoltam hátha már annak a megfixelése is segít.
|
mc68k
Tag
|
# Elküldve: 2015. Aug. 30. 07:00 - Szerkesztve: mc68k
Nem voltam elég világos, amikor írtam, hogy órákig kerestem a hibát, de végül meglett. Mi okozta? Ugyanaz, mint ennek, itt:
http://eab.abime.net/showthread.php?t=53527
Nem volt kitöltve az indextábla (0-ás indexek szerepeltek $18, $19 stb. helyett).
A kérdés inkább elméleti jellegű és véleményezési célzatú volt, illetve, hogy okosodjunk. Nem hiszem, hogy bárkinek is szemet szúrt eddig (Toni Wilen kivétel :) ), hogy van egy interrupt vector index tábla is a ROM-ban és nem automatikusan a megfelelő interrupt vektort veszi elő a CPU az IPL alapján, hanem pluszban indexelget is (Amigán).
Az UM írja ezt az 5-9 - 5-10-es oldalakon (IACK cycle, vector aquisition), csak tegnapig átsiklottam felette.
Ez a probléma akkor lép fel, ha custom ROM-ot akarunk elindítani. Gyári KS ROM mellett sohasem jelentkezik és nem is tudunk a létezéséről, hisz ott mindig ki van töltve az indextábla.
Tehát Amigán mindig FIX autovector tartozik a megfelelő IPL kombinációhoz, mert fix az indextábla és nem a periféria adja meg a vektor számát, IACK-on belül.
A hozzászólásban kizárólag autovector interruptokról írtam ($64 - $7c) és nem user interruptokról, valamint azért itt, hogy olvassa és okuljon más is belőle, mert ez számomra érdekes dolog volt (CPU space cycle).
|
Chain-Q
Divatamigás
|
# Elküldve: 2015. Aug. 30. 07:56 - Szerkesztve: charlie
@m68k:
és nem automatikusan a megfelelő interrupt vektort veszi elő a CPU az IPL alapján, hanem pluszban indexelget is (Amigán).
Najó de, ha már okosodunk - és okoskodunk - amennyire én értem Toni leírásából nincs itt pluszban indexelgetés hanem Amigán igazából a CPU nem is tudja hogy most egy autovector interruptot hajtott végre, hanem simán lezajlik az IACK ciklus, csak éppen az interrupt controller helyett a ROM "válaszol", hogy tessék paraszt itt egy érték (az autovector száma), DACK. Merthogy az $FFFFFFF<IPL> kerül a címbuszra IACK közben, ami a címtartomány vége, és ott a ROM van. Emiatt ugyan a megfelelő autovector interrupt hívódik meg, de a CPU számára ez közben egy normál interrupt volt. Ezzel olcsóbb lehetett a design, mert nem kellett komplex válaszolós interrupt controllert építeni, 16byte-nyi ROM terület árán. Beteg. :)
|
