Menù principale

Notizie  Grafica  Forum  Links  Retro Trailer  Recensioni  Modelli Amiga  Storia Amiga  Retro-Gamers  Lista Utenti  Contatti  Policy sito

Login

Nick Password

Registrati - Recupera dati

01 Maggio 2020 Postato da: divina AMOS Professional AGA

è arrivato AMOS Professional AGA (free, leggere con attenzione) http://amos-professional-aga.frederic-cordier.fr/?amos-professional-aga

Commenti: 33  Aggiungi - Pagine: 1-2

Indice: forum / Software Amiga in generale

Pagine: -1- [2] - Post inviati: 695 Commento 21 saimo 4 Febbraio 2022    19:37:35 Avenger75 A proposito di ALS, siccome ho intenzione di riprendere a smanettarci sopra, approfitto per chiedere se oltre a supportare AGA è anche in grado di superare il limite dei 1024 pixel di larghezza massima? Risposta secca per non allungare l'OT: no. RETREAM - sogni retro per Amiga, Commodore 64 e PC SysAdmin Unix/Linux - fiero o folle possessore di un AmigaOne Post inviati: 3207 Commento 22 VagaPPC 4 Febbraio 2022    20:13:30 Ho capito quello che dici, ma non tutti accedono a basso livello con AMOS, per la maggior parte di noi che non ha le tue competenze di programmazione ci sono magari piccoli programmi che abbiamo scritto per noi stessi che ci piacerebbe riprendere. La libreria in questione semplifica molto la vita, e comunque per accedere a basso livello siamo già in un ambiente C che è decisamente più pratico. Mentre al contrario la gestione di uno sprite o cose come il comando "boom" usare una sintassi AMOS semplifica molto la vita. Alla fine non fa altro che aggiungere i comandi AROS al C. Lo trovo molto comodo. Specie se volessi sviluppare un gioco in C. Hollywood, l'ho comprato ed è molto bello ed è comunque una valida alternativa. Se qualcuno è interessato la libreria che ho citato è questa: http://sharynn.free.fr/PURE%20C%20AMOS4%20SITE/ind ex.html Commento modificato il 04/02/2022 alle ore 20:16:06 WorkStation: Amiga x5000 AOS4.1 - MorphOS MiniMac - Vampire V4 - PC AMD Ryzen 9 7950X3D 64Gb RAM 5Ghz Old System Amiga 500,1200, A4000/60 PowerPPC, CybervisionPPC, SUN Ultra5, PowerMAC G4 450Mhz 1Gb Il Webmaster Post inviati: 4739 Commento 23 Mak73 4 Febbraio 2022    21:49:16 Scusa ma hai le idee un po' confuse, il C è un linguaggio di alto livello, l'assembly è di basso livello, praticamente un'altro pianeta. Pace e bene a tutti. SysAdmin Unix/Linux - fiero o folle possessore di un AmigaOne Post inviati: 3207 Commento 24 VagaPPC 5 Febbraio 2022    11:44:06 In risposta a Mak73 Mak73 Scusa ma hai le idee un po' confuse, il C è un linguaggio di alto livello, l'assembly è di basso livello, praticamente un'altro pianeta. Il C è un linguaggio di medio livello, oggi viene considerato anche di basso livello. In quanto è nato per astrarre l'assembler e girare su più HW e con l'avvento di Amiga (che fu il primo OS ad avere una buona compatibilità a livello di sorgenti con unix) anche su OS diversi. Non so cosa intende per alto livello, forse il C++ visto che astrae maggiormente la logica della Macchina. Anche nei libri di scuola di mio figlio ci sono altre fantasiose definizioni. Forse ci sarebbe da definire a cosa si riferiscono per basso e alto livello WorkStation: Amiga x5000 AOS4.1 - MorphOS MiniMac - Vampire V4 - PC AMD Ryzen 9 7950X3D 64Gb RAM 5Ghz Old System Amiga 500,1200, A4000/60 PowerPPC, CybervisionPPC, SUN Ultra5, PowerMAC G4 450Mhz 1Gb Post inviati: 126 Commento 25 Fl@sh 5 Febbraio 2022    12:50:22 Il C è decisamente un linguaggio di basso livello, più in basso c’è solo l’assembler o addirittura il linguaggio macchina. Il Webmaster Post inviati: 4739 Commento 26 Mak73 5 Febbraio 2022    12:57:44 In risposta a VagaPPC Il linguaggio più di basso livello e il linguaggio macchina , che praticamente non ha mai usato nessuno, questo perchè c'è l'assembly, che però non può essere interpretato dal processore ma ha il vantaggio che ogni sua istruzione è tradotta direttamente in linguaggio macchina, cioè ogni istruzione assembly al suo corrispettivo in linguaggio macchina. Sopra l'assembly sono considerati tutti di alto livello, questo perchè devono essere compilati, "tradotti" quindi in linguaggio macchina però questa "traduzione" può essere fatta più o meno bene, e questo fa si che un compilatore generi codice più performante di un'altro in certi contesti. Con AMOS lo svantaggio è che c'è solo il suo di compilatore, ed ovviamente non essendo degli esperti non si può sapere se il codice generato da questo vada bene o sia migliorabile. AMOS è studiato appositamente per i giochi, bypassa completamente il sistema operativo, quindi non hai una funzione per aprire una finestra sul workbench o cose simili come ad esempio succede con AmiBlitz. Grazie a questo AMOS risulta più facile, perchè lavora in modo diretto, tutte le funzioni per interfacciarsi con l'OS non esistono, perchè lui s'interfaccia direttamente con l'hardware, proprio per questo quando sono usciti gli AGA e il linguaggio non è stato aggiornato, non ha potuto osare le nuove funzionalità offerte dal nuovo chipset. Pace e bene a tutti. Post inviati: 695 Commento 27 saimo 5 Febbraio 2022    13:31:55 @VagaPPC VagaPPC Ho capito quello che dici, ma non tutti accedono a basso livello con AMOS, per la maggior parte di noi che non ha le tue competenze di programmazione ci sono magari piccoli programmi che abbiamo scritto per noi stessi che ci piacerebbe riprendere. La libreria in questione semplifica molto la vita, e comunque per accedere a basso livello siamo già in un ambiente C che è decisamente più pratico. Mentre al contrario la gestione di uno sprite o cose come il comando "boom" usare una sintassi AMOS semplifica molto la vita. Alla fine non fa altro che aggiungere i comandi AROS al C. Lo trovo molto comodo. Specie se volessi sviluppare un gioco in C. Hollywood, l'ho comprato ed è molto bello ed è comunque una valida alternativa. Se qualcuno è interessato la libreria che ho citato è questa: http://sharynn.free.fr/PURE%20C%20AMOS4%20SITE/ind ex.html Non avevo capito che ti riferissi a una libreria di questo tipo (di cui non conoscevo l'esistenza), anche perché non permette affatto "di compilare in C un programma AMOS", ma semplicemente permette di scrivere programmi in C facendo uso di funzioni e comandi tipo quelli dell'AMOS. Mi viene da fare allora altre considerazioni. Se l'obiettivo è semplicemente quello di fornire una libreria che in pratica è un layer di astrazione dall'OS con un vago "gusto AMOS", allora ha un senso; anche se, mi chiedo: a questo punto, al programmatore AMOS, visto che deve comunque scrivere codice in linguaggio C, non conviene studiarsi le SDL? OK, si perde il "gusto AMOS", ma quello, d'altra parte, è già perso al 90%, mentre le SDL offrono molto di più e sono mature. Se l'obiettivo è invece permettere di portare le vecchie applicazioni AMOS su Amiga NG (mi pareva fosse questo il succo della discussione), allora trovo questo tipo di approccio inutilmente e doppiamente faticoso (e destinato all'insuccesso). E' uno sforzo enorme per lo sviluppatore della libreria perché, in pratica, deve reimplementare AMOS (non basta riscrivere tutte le funzioni e i comandi del linguaggio, ma ci vuole un motore run-time che gestisca audio e video), ed è uno sforzo enorme per l'utente perché deve prendere il suo codice AMOS originale e riscriverlo in C. Chiarimento obbligatorio. Con quanto sopra, non voglio criticare i desideri e le preferenze di nessuno: ovviamente ognuno è libero di divertirsi come e fare quello che gli pare. Io stesso, con ALS, ho fatto uno sforzo largamente inutile, visto che è un prodotto di nicchia che difficilmente qualcuno userà (se non ci avessi fatto io stesso due giochi, sarebbe inutilizzato). L'ho fatto, come spiegato nella documentazione, principalmente per divertimento personale. Con le mie considerazioni intendo solo far riflettere bene sull'approccio di quella libreria C. @tutti Al riguardo di "basso livello": nel mio precedente post non si riferisce al linguaggio, ma all'uso delle risorse. Per capirci, ecco un paio di esempi di basso livello in AMOS (che non è un linguaggio di basso livello, anche se per gli standard moderni è rudimentale): * se, invece di usare i comandi di AMOS, programmo il Blitter direttamente con una serie di Doke, sto usando l'hardware direttamente e, quindi, sto lavorando a basso livello; * se, per accendere il pixel in alto a sinistra di uno schermo a 2 colori, invece di usare Plot 0,0,1, uso Bset 7,Phybase(0), sto manipolando direttamente la memoria dello schermo (presumendo che sia organizzata in modo planare) e, quindi, sto lavorando a basso livello. Lo stesso AMOS in alcuni casi si appoggia alle librerie dell'OS, in altri accede direttamente all'hardware e, quindi, lavora a basso livello. Commento modificato il 05/02/2022 alle ore 13:34:10 RETREAM - sogni retro per Amiga, Commodore 64 e PC Post inviati: 695 Commento 28 saimo 5 Febbraio 2022    13:47:20 Mak73 Con AMOS lo svantaggio è che c'è solo il suo di compilatore, ed ovviamente non essendo degli esperti non si può sapere se il codice generato da questo vada bene o sia migliorabile. Purtroppo, in merito c'è una certezza assoluta: il codice compilato di AMOS è inefficientissimo, sia come linguaggio macchina prodotto, sia come struttura. Nota divertente: le pagine 45 e 46 del compilatore magnificano la grande efficienza del codice prodotto; pagina 46, in particolare, mostra un pezzo di codice con questo commento: "Come si può vedere, questo codice è molto efficiente" - in realtà il codice, pur senza considerare l'architettura AMOS (che prevede la scrittura dei paramentri delle funzioni in uno stack puntato da a3 e il salto a una funzione della amos.library per ogni singola cosa, anche la più semplice tipo il già citato Bset), è oscenamente inefficiente a livello di linguaggio. Commento modificato il 05/02/2022 alle ore 13:48:00 RETREAM - sogni retro per Amiga, Commodore 64 e PC Il Webmaster Post inviati: 4739 Commento 29 Mak73 5 Febbraio 2022    15:53:35 In risposta a saimo saimo Purtroppo, in merito c'è una certezza assoluta: il codice compilato di AMOS è inefficientissimo, sia come linguaggio macchina prodotto, sia come struttura. Nota divertente: le pagine 45 e 46 del compilatore magnificano la grande efficienza del codice prodotto; pagina 46, in particolare, mostra un pezzo di codice con questo commento: "Come si può vedere, questo codice è molto efficiente" - in realtà il codice, pur senza considerare l'architettura AMOS (che prevede la scrittura dei paramentri delle funzioni in uno stack puntato da a3 e il salto a una funzione della amos.library per ogni singola cosa, anche la più semplice tipo il già citato Bset), è oscenamente inefficiente a livello di linguaggio. Se non ricordo male il compilatore era già criticato ai suoi tempi, perchè se ne era parlato molto, tanti si aspettavano chissà cosa viste le buone prestazioni della versione interpretata. Poi però le aspettative non furono soddisfacenti, e molti ne rimasero delusi. L'unico aspetto positivo era che si poteva ottenere un eseguibile autonomo. Pace e bene a tutti. Post inviati: 126 Commento 30 Fl@sh 5 Febbraio 2022    15:58:39 Purtroppo i compilatori sono largamente inefficienti, specialmente per il 68k dove l’architettura permette di arrivare allo stesso risultato seguendo innumerevoli strade. La cosa più bella è proprio quella di scrivere il codice critico direttamente in assembler. Per questo ancora oggi esistono numerosi coder che continuano a sfornare demo per gli amiga Classic. Il C però è l’unico linguaggio che grazie all’uso dei puntatori ed ad altre caratteristiche riesce a simulare in qualche modo il linguaggio assembler. Con un codice C scritto bene ed in maniera semplice posso immaginare in che modo il compilatore possa tradurre la sequenza di istruzioni, per questo è considerato a basso livello. I firmware di molti dispositivi hardware sono scritti sempre più in C, di contro l’assembler è sempre meno usato. In ogni caso scrivendo in assembler riesco sempre e comunque ad essere più compatto e veloce di qualsiasi compilatore, ora però ci dovremmo confrontare con le AI e sarà una bella gara se opportunamente addestrate. SysAdmin Unix/Linux - fiero o folle possessore di un AmigaOne Post inviati: 3207 Commento 31 VagaPPC 5 Febbraio 2022    21:19:04 Delle AI non mi preoccuperei di fatto sono degli automatismi con un nome che attira l'attenzione. Mentre riguardo al compilatore GCC che da quanto leggo in giro è il migliore, permette con un opzione di restituire il codice assembler da un comune codice C/C++, FreePascal, Object-C, ecc. Permettendo così di ottimizzarlo manualmente, Richard Stallman ha pensato a tutto. Inoltre ha diverse opzioni che permettono un ottimizzazione più profonda, dai semplici valori -o1, -o2 e -o3, che altro non sono che un raggruppamento di funzioni. Possiamo compilare affinché ci sia un eseguibile piccolo (o1) oppure più oneroso di ram e disco ma più veloce (o3). WorkStation: Amiga x5000 AOS4.1 - MorphOS MiniMac - Vampire V4 - PC AMD Ryzen 9 7950X3D 64Gb RAM 5Ghz Old System Amiga 500,1200, A4000/60 PowerPPC, CybervisionPPC, SUN Ultra5, PowerMAC G4 450Mhz 1Gb Post inviati: 126 Commento 32 Fl@sh 6 Febbraio 2022    00:27:52 Capisco cosa intendi ma questi automatismi se ben allenati sono davvero efficienti. E con il tempo migliorano sempre di più. GCC non è il migliore ma sicuramene quello che abbraccia la maggior parte delle architetture. Su x86 per esempio sia il compilatore Intel che quello Microsoft dovrebbero fare un pò meglio, soprattutto il primo con le librerie matematiche ottimizzate per Intel. Anche con GCC Puoi mostrare il codice assembler intermedio ma poi metterci mano è un'altra cosa, salvo che non si tratti di applicare piccole patch. Molto più semplice scriverti la tua funzione in assembler e magari usare il codice generato dal compilatore come spunto. Il Webmaster Post inviati: 4739 Commento 33 Mak73 6 Febbraio 2022    08:21:36 Stiamo andando OT, se volete apriamo un topic separato Pace e bene a tutti. Pagine: -1- [2] -

Indice: forum / Software Amiga in generale

Utenti Online

Utenti registrati: 1206 dal 1 Gennaio 2006 di cui online: 0 registrati -  e 29 non registrati Benvenuto all'ultimo utente registrato: zulu Buon Compleanno a nubechecorre - gira93 - 46337 -