Salve , sono un collezionista e un appassionato di console ! Vorrei fare dei progetti per PSX , soprattutto sono un patito di INTRO e "cracktro" ... mi consigliate delle buone librerie ( devono funzuionare senza farmi uscire pazzo 1230430 volte ) per lo sviluppo di homebrew per PSX ?
Fate conto che programmo in C , quindi per favore niente asm XD
Facendo riferimento a questo vecchissimo topic : http://www.romhacking.it/forums/index.php?topic=1067.0 , vorrei capire quali sono i punti a sfavore delle Blade Libs ...
Conto nel vostro aiuto ...
PS: quando ho visto che esisteva un forum italiano sul rom hacking , ke trattava anche argomenti di sviluppo per retroconsole , mi sono subito brillati gli occhi ... confido su di voi :'D
Il kit di Blade sostanzialmente ha problemi a funzionare sull'hardware vero e proprio (ergo, blocchi di sistema in determinate situazioni), mentre ha effetti quasi casuali di malfunzionamento sui vari emulatori. Inoltre mancano diverse funzioni (principalmente asincronia, se non ricordo male) e alcune librerie funzionano un po' come gli gira, come il modulo per la SPU che a volte non lancia alcun suono in esecuzione.
Se vuoi un SDK gratuito e decisamente più aggiornato e funzionante, buttati sulla roba di tails92/nextvolume: http://gamesource.groups.yahoo.com/group/psxdev/
In alternativa, recupera direttamente l'SDK ufficiale e usalo senza troppe remore di infrangere copyright o altro. È talmente tanto vecchio e deprecato che dubito freghi più veramente qualcosa alla Sony. Senza contare che rimane ancora il miglior strumento per sviluppare applicazioni e giochi PlayStation senza incappare in strani malfunzionamenti dovuti a caratteristiche non documentate della console.
Grazie 1000 gemini per il tuo prezioso aiuto ...
Allora comincio a dire che :
CitazioneIn alternativa, recupera direttamente l'SDK ufficiale e usalo senza troppe remore di infrangere copyright o altro. È talmente tanto vecchio e deprecato che dubito freghi più veramente qualcosa alla Sony. Senza contare che rimane ancora il miglior strumento per sviluppare applicazioni e giochi PlayStation senza incappare in strani malfunzionamenti dovuti a caratteristiche non documentate della console.
Ho tentato un sacco di volte di usarlo ... ogni volta ke riesco a trovarlo mancano sempre dei files fondamentali , oppure sono danneggiati :(
Piu tardi do un'occhiata al link di tails92 ;)
PS: posso contare sul tuo aiuto se avro' problemi ? sono anni che cerco di produrre qualcosa per PSX ...
Chiedi pure. Alla fine siamo rimasti in due precisi (io e nextvolume) a lavorare attivamente sul programmi per PlayStation. Mi può fare solo piacere che la scena del software fatto in casa si espanda, anche se a quanto pare siamo solo noi italiani ad avere questo genere di interesse. ???
Citazione di: Avanaboy il Giugno 05, 2011, 14:57:30Ho tentato un sacco di volte di usarlo ... ogni volta ke riesco a trovarlo mancano sempre dei files fondamentali , oppure sono danneggiati :(
Che file mancherebbero esattamente? Io sviluppo proprio con l'SDK Psy-Q e non ho mai avuto problemi di configurazione, a parte con le versioni più antiche che ormai non sono compatibili con nessun sistema operativo se non Windows 98.
Confermo anch'io che le Psy-Q funzionano senza problemi. Addirittura io le usai per sviluppare il sistema di softsub per FF7. Prova a farti un giro sul vecchio sito di Brisma, lì dovresti trovare qualcosa.
Io l'ho preso su due siti diversi ... il 4.3 se non sbaglio ... non sono mai riuscito a compilarci nulla , mancavano file , e altri eseguibili erano danneggiati ... io l'ho usato su XP ... potrebbe essere questo il problema ? cmq ora provo a riscaricare il tutto e vedere se riesco a capirci qualcosa ;)
EDIT: gemini che versione di psyq usi tu ?
EDIT2: dopo tanti sforzi sembra che sono riuscito ad ottenere una versione di psyq ( aggiornata da 3.qualcosa a 4.6 ) ... mi chiedevo pero' se è normale che mancano i vari tool per convertire le immagini in .tim e altro ... fatemi sapere ;) (cmq sto usando dosbox per far funzionare il tutto ...)
dosbox non serve, ricordo che bastava inserire nella cartella bin di psyq un programma per la compatibilità dos, credo si chiamasse dos4gw.exe. Forse quello però serviva per il cpe2exe.exe (che non mi sembra sia presente in psy-q, credo sia opera degli hitmen).
Esatto .... mi sono appena accorto ke cosi non si puo' lavorare ... mi sa che installo una macchina virtuale ( sono a 64 bit , non posso lavorare con dos4gw :( ) ...
Phoenix , tu lo psyq 4.6 lo hai testato su XP ? mi assicuri la compatibilità ?
aspetto tue risposte ;)
Il 4.6 lo uso io su XP ed è configurato per lavorare in combo con Visual Studio 2010 tramite progetto Makefile, per cui compatibilità totale su tutti i fronti. Questa è la toolchain che utilizzo:
CC = ccpsx
ASM = asmpsx
LINK = slink
LIBLNK = psylib2
Al posto di CPE2EXE basta usare CPE2X, che mi pare sia l'alternativa aggiornata e funzionante di Hitmen.
Perfetto , sto facendo una macchina virtuale per usare il tutto ;)
Grazie anche a Phoenix , che mi sta aiutando molto ;)
[edit]Allora , ottime notizie ...
sembra funzioni tutto , ho provato a compilare un paio di sorgenti degli esempi ,e a convertire il file cpe in file exe con CPE2X ... l'emulatore lo legge alla perfezione ;)
Domani iniziero' il lavoro di coodin piu serio ... speriamo bene !!
Vi aggiornero' regolarmente :) GRAZIE per l'aiuto datomi sino ad ora ! :)
Allora , iniziamo con alcune domande :
Ho visto si negli esempi del kit , sia nelle guide , che per caricare immagini e file audio , questi vengono direttamente spediti nella ram della console via cavo ... oppure vengono inseriti in file .h ( per farlo che programma si usa ? va bene il classio bin2h ? non credo... ) ... Non esiste nessuna API per caricare "al volo" da CD una immagine tim ? ???
aspetto i vostri chiarimenti ;)
Non ho mai usato funzioni di lettura da CD in Psy-Q. Però da quel che leggo dalla documentazione, sembra basti usare
CdRead(int numSettoriDaLeggere,char* bufferLettura,int mode);
preceduta da un CdlSetLoc che indica da quale settore iniziare a leggere.
Il valore mode è specificato dalla tabella 10-4 della libref46.pdf, che dovrebbe indicare la modalità di accesso al disco (double speed, streaming ecc.).
Aspetto cmq gemini per maggiori delucidazioni.
N.B. CdlSetLoc è un command da inviare tramite la funzione CdControl.
Per quanto riguarda i .h, ci dovrebbero essere funzioni per la gestione dell'header tim e del loro contenuto nella psyq. Quindi, sì, credo basti convertire con bin2h la tim in .h, e tramite puntatori alla struttura nel .h usare le funzioni di gestione delle TIM.
Se vuoi una funzione rapida e non particolarmente complessa (tradotto: niente processi asincroni) puoi usare CdSearchFile in combinazione con CdControl e CdRead. Anzitutto inizializza il sistema del CD inserendo CdInit da qualche parte dopo ResetCallback().
Un esempio di come inizializzo io la console:
void InitSys()
{
extern _GsPOSITION POSITION;
extern DRAWENV GsDRAWENV;
extern DISPENV GsDISPENV;
ResetCallback();
InitializeCardAndEvents(0);
//InitThreads();
CdInit();
FS_Init();
ResetGraph(0);
SetGraphDebug(0);
InitControllers();
// sound shit
SsInit();
menu_vab=SsRmsLoad("MENU.RMS");
SetVideoMode(MODE_NTSC);
GsInitGraph(FRAME_X,FRAME_Y,GsOFSGPU|GsNONINTER, 1, 0);
GsDefDispBuff(0,0,FRAME_X,0);
WorldOrderingTable[0].length=OT_LENGTH;
WorldOrderingTable[0].org=zSortTable[0];
WorldOrderingTable[1].length=OT_LENGTH;
WorldOrderingTable[1].org=zSortTable[1];
Init3D();
ClearFBuffer(0,0,1024,768); // clear all the bios textures
VSyncCallback((void (*)()) VSyncCB);
}
Per quanto riguarda il corpo della funzione di caricamento dei file (presa da alcuni sorgenti d'esempio ufficiali):
int _read1(long byte, void *sectbuf, int mode)
{
int nsector,cnt;
nsector=(byte+2047)/2048;
// read start
CdRead(nsector, sectbuf, mode);
while((cnt=CdReadSync(1,NULL))>0) VSync(0);
return cnt;
}
CdlFILE* file_read(char *fname, void *address)
{
int mode = CdlModeSpeed;
int cnt,i;
DEBUGPRINT(("Loading %s at %x\n",fname,address));
for (i = 0; i < 10; i++) // 10 times retry
{
if (CdSearchFile(&fp, fname) == 0)
continue;
// set target position
CdControl(CdlSetloc, (u_char *)&(fp.pos), 0);
cnt = _read1(fp.size,address,mode); // read
// if it success, break
if(cnt==0)
return(&fp); // success
}
DEBUGPRINT(("%s: cannot read\n", fname));
return 0; // fail
}
Richiama file_read, poi passagli come parametri fname per il nome del file da caricare (metti un ";1" a fine stringa altrimenti non caricherà nulla, es: "\DATA\IMG.TIM;1") e address per la destinazione in ram.
PS: Per cortesia, evita di postare nuovi messaggi a breve distanza. Usa il tasto modifica, tanto il topic risulterà in ogni caso visibile come se una nuova risposta fosse stata postata.
Grazie 1000 per il codice di init , utilissimo !!
Guardando un po questi due sorgenti che mi hai postato , ho visto che non usi _96_init() che a quanto ho capito dovrebbe inizializzare i driver necessari alla lettura del cdrom :-\
come mai questa scelta ?
PS: spero che non vi scocciate di aiutarmi ad imparare ;) usero' il tasto edit in caso :)
EDIT: cosa è questo "InitializeCardAndEvents(0);" ? nella reference del 4.6 nn l'ho trovato ??? ... e neanche FS_init() e InitControllers... sono funzioni tue vero ? :)
Citazione di: Avanaboy il Giugno 07, 2011, 15:14:04Guardando un po questi due sorgenti che mi hai postato , ho visto che non usi _96_init() che a quanto ho capito dovrebbe inizializzare i driver necessari alla lettura del cdrom :-\
come mai questa scelta ?
Perché _96_init() dovrebbe essere già all'interno di CdInit(), insieme ad altra roba delle librerie del CD.
CitazioneEDIT: cosa è questo "InitializeCardAndEvents(0);" ? nella reference del 4.6 nn l'ho trovato ??? ... e neanche FS_init() e InitControllers... sono funzioni tue vero ? :)
L'SDK è sempre lo stesso, per cui sì, è tutta roba mia.
Scusa , forse questa domanda è molto stupida : ma è possibile che non si possono dichiarare varibili interne al main ? Ho deciso di iniziare scrivendo un semplicissimo programma ke alla pressione dei tasti del joypad cambia il colore dello schermo , ma se dichiaro varibili interne al main ( tipo int r,g,b; ) vengono ignorate ... è possibile ? ???
PS: per la cronaca cmq sono riuscito a fare questo semplice programmino ;) ( se pensi possa servire a qualcun altro posto il source )
EDIT: sapresti per caso dirmi dopo vengono indicate le keyword del pad scritte in libetc.h ? ad esempio PADLup equivale a freccia su , ma per i tasti X O [] e /\ ? ci sono i,j,k,l,m,n,o,h xo' sono per i tasti L1 L2 ecc... grazie ;)
Citazione di: Avanaboy il Giugno 07, 2011, 17:14:14Scusa , forse questa domanda è molto stupida : ma è possibile che non si possono dichiarare varibili interne al main ? Ho deciso di iniziare scrivendo un semplicissimo programma ke alla pressione dei tasti del joypad cambia il colore dello schermo , ma se dichiaro varibili interne al main ( tipo int r,g,b; ) vengono ignorate ... è possibile ? ???
Mi sembra strano. Io ho sempre avuto variabili interne al mio main e non è mai successo nulla. Esempio:
int main()
{
int i;
u8 *seq, *bnk, *tim;
char string[2048];
extern SSEQ_STATUS seq_env;
char voice_status[NUM_SFX_VOICES];
DEBUGPRINT(("--------------------\n"));
//DEBUGPRINT(("Heap position %x, size %d KB\n",(u32)heap_base,(STACK-(long)heap_base)/1024));
DEBUGPRINT(("Heap position %x, size %d KB\n",(u32)heap_base,(STACK-(u32)heap_base)/1024));
InitHeap3((u32*)heap_base,STACK-(u32)heap_base);
InitGfxAlloc(128*1024);
InitSys();
// kernel
FS_Load("SEQ.BIN",ARCHIVE_SYSTEM,SSeqAddress);
tim=(u8*)FS_Load("FONT.TIM",ARCHIVE_DATA,NULL);
LoadTim((long*)tim);
free3(tim);
// sound
menu_vab=SsRmsLoad("07.RMS");
seq=(u8*)FS_Load("07.SEQ",ARCHIVE_DATA,NULL);
bnk=(u8*)FS_Load("07.BNK",ARCHIVE_DATA,NULL);
SSeqOpen(seq,bnk);
while(1)
{
BeginDraw();
//
sprintf(string,"Tempo %d (%d/240)",seq_env.tempo,seq_env.timer);
Print8String((u8*)string,20,20);
SpuGetAllKeysStatus(voice_status);
for(i=0; i<SSEQ_MAX_TRACK; i++)
{
sprintf(string,"Track %02d: %d %x",i,voice_status[i]==SPU_ON ? 1 : 0,seq_env.track[i].voice.sample_note);
Print8String((u8*)string,24,32+i*12);
}
// callback
SSeqPlaying();
//
EndDraw(0,128,128);
}
}CitazionePS: per la cronaca cmq sono riuscito a fare questo semplice programmino ;) ( se pensi possa servire a qualcun altro posto il source )
Posta posta, male non farà sicuramente.
Citazionesapresti per caso dirmi dopo vengono indicate le keyword del pad scritte in libetc.h ? ad esempio PADLup equivale a freccia su , ma per i tasti X O [] e /\ ? ci sono i,j,k,l,m,n,o,h xo' sono per i tasti L1 L2 ecc... grazie ;)
Libetc ha delle macro che effettivamente fanno schifo. Usa queste definizioni per semplificarti la vita:
#define R2_KEY PAD_FRB
#define L2_KEY PAD_FLB
#define R1_KEY PAD_FRT
#define L1_KEY PAD_FLT
#define TRIANGLE_KEY PAD_RU
#define X_KEY PAD_RD
#define SQUARE_KEY PAD_RL
#define CIRCLE_KEY PAD_RR
#define UP_KEY PAD_LU
#define DOWN_KEY PAD_LD
#define LEFT_KEY PAD_LL
#define RIGHT_KEY PAD_LR
#define SELECT_KEY PAD_SEL
#define START_KEY PAD_START
Allora , ecco a voi il codice che cambia il colore dello schermo premendo il tasto X . Magari il codice non è molto buono e ordinato , ma sto imparando ora ad usare queste funzioni , quindi abbiate pietà XD
Non so se postarlo qui o creare un topic apposito a questo e ai sorgenti futuri ... dimmi tu gemini ;)
/* Cambia colore dello schermo premendo il tasto X */
/* Avanaboy 08/06/2011 */
#include <sys/types.h>
#include <libetc.h>
#include <libgte.h>
#include <libgpu.h>
DRAWENV draw;
DISPENV disp;
int r=0,g=0,b=0;
RECT rect;
u_long padd;
main(){
ResetCallback();
SetVideoMode(MODE_PAL);
ResetGraph(0);
SetGraphDebug(0);
PadInit(0);
SetDispMask(1);
setRECT(&rect, 0, 0, 640, 480 );
ClearImage(&rect, 0, 0, 0);
SetDefDrawEnv(&draw,0,0,640,480);
SetDefDispEnv(&disp,0,0,640,480);
KanjiFntOpen(16,16,640,400,704,0,768,256,0,512);
while(1){
padd = PadRead(1);
if(padd & PADRdown){
r=rand();
g=rand();
b=rand();
ClearImage(&rect, r, g, b);
}
KanjiFntPrint("Premi il tasto X per cambiare colore !\nBy Avanaboy");
KanjiFntFlush(-1);
PutDispEnv(&disp);
PutDrawEnv(&draw);
}
}Come puoi vedere ho dovuto dichiarare le var fuori , altrimenti psymake mi diceva ad esempio "draw undeclared , first use in this function" , e non riesco a capire il perchè , sicuramente sbaglio qualcosa , ma cosa ?
Ad ogni modo ho provato questo codice su ePSXe e sembra funzionare molto bene ;)
CitazioneLibetc ha delle macro che effettivamente fanno schifo
Eh si , ho capito solo dopo alcune ore che il tasto X era in realtà PADRdown XD :)
Sicuro di aver dichiarato le variabili in maniera corretta? Il vecchio standard prevede una dichiarazione formale senza alcun passaggio di valori, che va fatto solo dopo. In pratica il tuo codice sarebbe dovuto essere così:
main()
{
DRAWENV draw;
DISPENV disp;
RECT rect;
u_long padd;
int r=0, g=0, b=0;
...
}
Se non direttamente in quest'altra maniera:
main()
{
DRAWENV draw;
DISPENV disp;
RECT rect;
u_long padd;
int r, g, b;
r=g=b=0;
...
}
Altra cosa: sarebbe meglio evitare funzioni com PadInit e PadRead, come sconsigliato anche nella reference. Non permettono il supporto di svariati tipi di controller, Dual Shock compreso. Se proprio vuoi delle funzioni serie prova control.c (http://pastebin.com/14qKY3En), control.h (http://pastebin.com/Ec87vBYF) e ctrller.h (http://pastebin.com/QaYxWdDk).
CitazioneSicuro di aver dichiarato le variabili in maniera corretta?
Ho provato a fare come dici tu , pero' stesso identico errore : "parse error before 'rect' ... rect undeclared first use in this function" :(
Citazionesarebbe meglio evitare funzioni com PadInit e PadRead
Eh si lo avevo letto anche io , pero' ho usato queste perchè le ho capite meglio dato che erano presenti negli esempi ufficiali ... quindi al posto di PadInit , mi consigli InitPad ? fammi sapere , cosi mi studio quelle giuste ;)
Sostituisci InitControllers a PadInit e GetPadValue a PadRead;
CitazioneSostituisci InitControllers a PadInit e GetPadValue a PadRead;
Ma dove si trovano ste funzioni ? ??? non sono tarttate nella reference :-\
Guarda nel post con gli esempi della main, ho messo i link in fondo.
Aggiunti ;)
Gemini cmq è molto strano quel fatto delle variabili ...
EDIT : maledizione avevo letto male il tuo messaggio di prima e stavo uscendo pazzo con sto fatto delle varibili !! :-[ , avevi ragione , l'inizializzazione viene fatta alla fine , in questo modo funziona tutto dichiarato anche dentro il main ;)
PS: vediamo se nel tardo pomeriggio riesco a studiarmi le funzioni necessarie per mettere un'immagine di background ;)
La gestione delle immagini è abbastanza rognosa, soprattutto tra caricamenti in VRAM e mappaggio via pagine, sprite e poligoni. Ti aspetta un bel percorso ad ostacoli fatto di smadonnamenti e tanti, tanti tentativi. Attento soprattutto a imparare bene come usare le direttive SPRT e POLY, e quando evitare di usare queste ultime.
Allora sto gia uscendo un po pazzo con questa parte grafica ::)
Visto che il caricamento delle immagini .TIM a quanto ho capito si puo' fare solo da CD ( con le funzioni che mi hai illustrato nella prima pagina ... ) è possibile in qualche modo caricare immagini senza usare la lettura del disco per identificarle ?
ad esempio convertirle in file .h ... come si potrebbe fare quindi ? ( ne avevamo parlato molto sommariamente prima )
PS: quando tu mi hai detto che avrei dovuto caricare il file .tim ad un indirizzo della ram , intendevi un indirizzo preciso o uno casuale ( che poi devo specificare nel source ) ?
Ti faccio un esempio preso dal mio motore. Questa funzione serve per caricare una TIM da RAM in VRAM:
void LoadTim(long *tim)
{
GsIMAGE image;
GsGetTimInfo((u_long *)tim+1, &image);
LoadImage((RECT*)&image.px, image.pixel);
if(image.pmode&8) LoadImage((RECT*)&image.cx, image.clut);
DrawSync(0);
}
Tu devi passargli solo il puntatore dei dati in RAM, poi il resto lo fa lui.
Ora, quest'altro è un esempio di caricamento da CD di un file TIM:
tim=(u8*)FS_Load("FONT.TIM",ARCHIVE_DATA,NULL);
LoadTim((long*)tim);
free3(tim);
La mia funzione FS_Load carica il file FONT.TIM da un archivio e restituisce un puntatore, quel puntatore lo passi a LoadTim e poi lo liberi con free3 (in FS_Load viene richiamato internamente malloc3, ecco perché serve liberare il puntatore). Dopo questo passaggio la TIM è bella che caricata in VRAM alle coordinate specificate dall'header del file. Se tali coordinate non ti vanno bene, gioca un po' con i parametri di LoadImage.
Se vuoi replicare la stessa cosa con un file .h, lo includi regolarmente e poi passi l'array lì contenuto come parametro per LoadTim.
mmm , ho bisogno di diverse ore per capire al meglio i tuoi esempi stavolta ;) diciamo che sto iniziando gia da ora a fare tentativi per capirne il funzionamento ;)
ma avendo una immagine .TIM , con che programma la converto in un file .h ? ( ho provato dei programmi tipo bin2h , ma danno risultati sballati ! :o )
PS: cmq gemini ti ringrazio davvero infinitamente ... mi sembra un sogno che inizia a realizzarsi ( dopo innumerevoli tentativi falliti ) ::) :P (ovviamente sono ancora all'inzio inizio eh ..)
Io ne uso uno che si chiama WinBin2Src che funziona benissimo, anche se non lo uso granché. Se devo includere risorse binarie di norma vado via script assembly.
quel programma che mi hai dato tu , restituisce output unsigned char del tipo : "0x2C" , invece nei sorgenti di esempio vedo immagini ( sempre sotto forma di file .h ) con static u_long del tipo "0x54321000" , infatti se compilo i risultati sono errati :(
Puoi chiarirmi le idee ? ;)
EDIT: a cosa servono i files descriptors ?
Non vedo il problema, ai dati grezzi inseriti nel .h si può applicare un cast a quel che si vuole. Puoi anche creare un .h con i char*, e poi sostituire "char" con "u8" (mi sembra sia definito in psyq), Poi, quando devi usare le funzioni che richiedono u_long, fai un cast.