Daedalus Shifty Beta 1 release

[funkman]

Edit by zion - FAKE, until proven otherwise

[Emeriastone]

I'm still curious as to why StrmnNrmn hasn't been heard from for so long, but that's his deal I suppose.

[V3N0M]

So if this an unofficial version?

[Mr. Shizzy]

Nice. I'll take any updates at this point. :) Downloading now...

[funkman]

no, this is an official release. Shifty(a friend from school), has told me to release this onto DCemu because he doesn't have an account here and says he doesnt have time to make one.

This is only a beta version of Daedalus Shifty though, so it would be nice if you could leave comments on how well games run and what you would like to see added to future versions.

[gunntims0103]

can anyone test this and post the speed difference from the officail release and this unofficail one

[SnoopKatt]

I'll test Super Mario 64 for you guys :)

[Zion]

20-25 fps in the opening scene

15-19 fps in castle and outside

10-13 fps in game.

in super mario 64, i think this is fake.

the old daedalus was the same as this

[funkman]

When I played Mario64, the framerate improved quite a bit in smaller areas or areas with less textures.

but make sure you use .z64 to get the better performance, or any other file for more textures

[SnoopKatt]

Ok, I walked around outside, and I got around 6.5-7.5 FPS
EDIT: Nevermind, I turned on dynamic recompiler, and it works at about Zion's speeds.

[gunntims0103]

we will need the source to see what changes he made and such

funkman tell your friend shifty to get the source ready and give it to you that way coders can comfirm weather there have actually been any changes

[turtleguy101]

wtf a fake for sure? thats gay. if there arnt any speed improovements in mario, the game daedalus was based off of, this cant be real.. unless its just compatability update... ile wait for more posts before downloading...

[Wally]

Wow what a cheap rip off..

Can i ask the following questions
a) Why is it called Daedalus Wally @ the eboot
b) Why does it contain a DS_Store file, you have no real excuses unless the person uses a mac to compile his projects



I doubt this is a geniune, and just a blant way of getting credit from someone elses work... Quote me if im wrong.

[gunntims0103]

only the source can tell. which this user probally doesnt have. Most likly a fake then :(

[funkman]

did you use .z64 rom?

from what Shifty has told me, it has improved framerate in mario 64 in smaller areas (go into the castle) and some more games are compatible with it, like doom 64, but i cannot confirm this.

please be aware that this is a beta version and that I did not develop it (i cannot code).

and once again i apologize to any expectations not met or any false statements that I have made, so please excuse my being a n00b

[sroon]

HAHAHAHA good boy Wally!
maaan I hate fakes lol! it doesnt even have the fixes Wally made as in the mux and the blond modes lol!
Maaaan guys just use Wallys hez the one doing the hard work not the Other dood!
( O )( O )

[Mr. Shizzy]

I just tested. Not to be rude, but this didn't seem to perform well. I tested Mario 64 (.v64) The texures looked like Deadleus R7. The speed may have been marginally faster. I really couldn't tell.
Also tested MK Trilogy. Was definently a step back. Funkman- thank you for taking the time to share with us. but could you please ask your friend to release the source? I think that would lay to rest any doubt if he coded it or not. :)

[funkman]

I can give you all the source code on monday.

I was told it was built off of Daedalus R8, but it could be off Spiff-Up.

Really it is just a compatibility update from what I have experienced, but if there is anything I have missed that should be included, I will post it on Monday.

and please make sure you are using .z64 rom files, because I have got framerate improvements in some areas of Mario 64 with the right file

[Wally]

Spiff UP's Source hasnt been released..

I am glad to release it, will do soon after tidying up the file for the GFX

[Jonesyxxiv]

no, this is an official release. Shifty(a friend from school), has told me to release this onto DCemu because he doesn't have an account here and says he doesnt have time to make one.

This is only a beta version of Daedalus Shifty though, so it would be nice if you could leave comments on how well games run and what you would like to see added to future versions.

Why did you say this is an official release if it isnt?

[mr.oddball]

dont complain guys, anything promoting daedelus development is good

[despoteuodia]

no, this is an official release. Shifty(a friend from school), has told me to release this onto DCemu because he doesn't have an account here and says he doesnt have time to make one.

This is only a beta version of Daedalus Shifty though, so it would be nice if you could leave comments on how well games run and what you would like to see added to future versions.
well, i think everyone would like to have sram and/or save states, who wants to restart every time they play sm64? or any other game?:confused: oh well, good job.

[samthegreat68]

how well does star fox 64 run? anybody know?

[XioN980]

Ok, firstly, who the hell made this?
secondly, StrmnNrmn is fine ;)
Thirdly: Not gonna Download it, waiting for spiff ups and REAL releases
Fourthly: Save a Tree, Eat a BEaver

[samthegreat68]

so why dosnt this come with two folders? normally theres folder and another with a % sign at the end. am i supposed to kxploit it or something?

[Tetris999]

Ok, firstly, who the hell made this?
secondly, StrmnNrmn is fine ;)
Thirdly: Not gonna Download it, waiting for spiff ups and REAL releases
Fourthly: Save a Tree, Eat a BEaver

no, its
Save trees, kill beavers

[zidanerick]

This is absolute crap, its just Daedalus 1.2 with a diff background, and yes all my roms are z64, and no there are no speed improvements, if anything the regular spiff-up is faster, in future make sure your friend doesnt rip people off before posting!!

[Accordion]

hee haw

[gelon]

Rige Racer 64 ~13 FPS ingame

http://i8.photobucket.com/albums/a43/stranno/sd0000.png

http://i8.photobucket.com/albums/a43/stranno/sd0002.png

Nuclear Strike 64 ~8 FPS ingame

http://i8.photobucket.com/albums/a43/stranno/qsd0002.png

http://i8.photobucket.com/albums/a43/stranno/qsd0001.png

Super Mario 64 ~22 FPS ingame

http://i8.photobucket.com/albums/a43/stranno/sd00500.png

http://i8.photobucket.com/albums/a43/stranno/sd05001.png

Aerogauge ~14 FPS (trial) ~10 FPS (cup)

http://i8.photobucket.com/albums/a43/stranno/sd0000-1.png

Airboarder 64 ~3 FPS ingame

[Baboon]

Shifty by name, shitty by nature??

[Tinnus]

He said it's anofficial release. Officially from his friend :rolleyes:

Just so you know, "official" means "done by the official dev team" and that's StrmnNrmn.

And the source? You know, that thing is GPL. The source *must* be released (or sent to) as soon as someone asks, and well, I'm asking.

It's not cool to release someone else's work with an update that you don't even know for certain what it does.

I did release a Daedalus "rip-off" once, but it was just because of the control stuff. I changed it myself for my own fun, but I thought other people should also have it ASAP so I released it. It wasn't my objective to gain attention though, just let people have fun with a quick fix in the code. And yes, I didn't release the source, but well, I just changed the same word in the same function call in the 5 times it appeared in the emulator code. I think Windows Exporer search function would do the trick in the case you wanted to see my changes ;)

[mnuhaily22]

This is the old spiff up, just copied onto this, with a diff background.

[blackrave]

Really?
I had hopes for this, but seems this is a real fake. Looking forward to the source code is released so someone can compare it with Wally's (I can't. :p)
funkman: Sorry, but I'm very disappinted..

[Exophase]

I don't think a single PSP dev respects the GPL except for Zx-81. You guys are lucky StrmnNrmn doesn't care because when people do stuff like this to my emulator I don't let them get away with it :P

Tinnus, you should release a patch when you do stuff like that. A patch and a link to what you patched it off of.

[Apoklepz]

Well, my hopes were high on this one...Drag...it really ain't nothing special. Move along folks.

[spiderjames]

meh...

[mlcurly16]

either way, great news!

[Tinnus]

Tinnus, you should release a patch when you do stuff like that. A patch and a link to what you patched it off of.
It was a single function that changed the name (ReadBuffer to PeekBuffer). And that change was going to be made by StrmnNrmn anyway... I just wanted to give people something quick to play with.

Although, looking back now I feel kind of silly... Like I drew too much attention to myself over something small. I feel kinda bad for looking like I stole someone's work and such...

In the case of H.O.T.A. the only reason I didn't release the code at first is because I was lazy :p But I did it as soon as the guy--the author by chance, but could've been anyone--asked.

[Shifty_]

Testing Testing 123

[Shifty_]

I am sorry for all the confusion. funkman is a friend of mine at school (yes I am only in High School, Grade 10, been working with C since I was 9) . I had asked him to maybe, perhaps release the mod for Daedalus that I was working on. Now, a little info, for all of you ppl who think that all I did was rip Wally and StrmnNrmn.

1) It has not been completed enough to actually be judged. This was just a quick build, to test whether or not it could actually be used with one of my new ideas.

2)My new idea was to not play around with the framerate of the actual emulator, but only with the actual roms.

3)My intended way of doing so, was to create a nice small, compact function, that would be called to load the entire rom into memory, dynamically edit the rom upon loading to basically say, 'go faster', run this through the entire rom, unload the rom, except for the part that was changed, then resume with the actual emulation. This function is only to be called once, after you choose which rom to load. In the end, this would not save and modifications made to the actual rom upon loading.

4) I am sorry that I had failed to explain this to funkman.

5) Now just to let you know, I have changed a rom(SuperMario64) in a rom modifier, and booted it up on good ol' Daedalus Wally to test it. It worked, it had a smoother, faster moving feel to the game, running at what looks to be "almost full speed", ALTHOUGH THE ACTUAL FRAMERATE MY NOT CHANGE
Now you may be thinking that this is similar to frameskip, but in fact it isn't. It is somewhat hard to understand the logic of how the human eye may see somthing one way, then they see it another way.

6)All I have done with the unoffical release that was given to funkman, was insert a function in the file 'daedalus\Source\Interface\RomDB
that is called upon loading a rom

7)Once again, I am sorry. This was just a one day thing so far, so when I get my dynamic rom speed modifier working for daedalus, you can probably expect to see what funkman had originally said, that I will get it to run at full speed.

If I have time I might work on some sort of interface so ppl can play around with a few of the settings.


Currently i am working on the rom modifyer, so expect some major speed increase within the next month or so. Until then

EMAIL ME, don't include hate mail, i alread read enough of that here.

[email protected]

shifty_

PS the name 'shifty' was already taken...*******

[Shifty_]

I am sorry for all the confusion. funkman is a friend of mine at school (yes I am only in High School, Grade 10, been working with C since I was 9) . I had asked him to maybe, perhaps release the mod for Daedalus that I was working on. Now, a little info, for all of you ppl who think that all I did was rip Wally and StrmnNrmn.

1) It has not been completed enough to actually be judged. This was just a quick build, to test whether or not it could actually be used with one of my new ideas.

2)My new idea was to not play around with the framerate of the actual emulator, but only with the actual roms.

3)My intended way of doing so, was to create a nice small, compact function, that would be called to load the entire rom into memory, dynamically edit the rom upon loading to basically say, 'go faster', run this through the entire rom, unload the rom, except for the part that was changed, then resume with the actual emulation. This function is only to be called once, after you choose which rom to load. In the end, this would not save and modifications made to the actual rom upon loading.

4) I am sorry that I had failed to explain this to funkman.

5) Now just to let you know, I have changed a rom(SuperMario64) in a rom modifier, and booted it up on good ol' Daedalus Wally to test it. It worked, it had a smoother, faster moving feel to the game, running at what looks to be "almost full speed", ALTHOUGH THE ACTUAL FRAMERATE MY NOT CHANGE
Now you may be thinking that this is similar to frameskip, but in fact it isn't. It is somewhat hard to understand the logic of how the human eye may see somthing one way, then they see it another way.

6)All I have done with the unoffical release that was given to funkman, was insert a function in the file 'daedalus\Source\Interface\RomDB
that is called upon loading a rom

7)Once again, I am sorry. This was just a one day thing so far, so when I get my dynamic rom speed modifier working for daedalus, you can probably expect to see what funkman had originally said, that I will get it to run at full speed.

If I have time I might work on some sort of interface so ppl can play around with a few of the settings.


Currently i am working on the rom modifyer, so expect some major speed increase within the next month or so. Until then

EMAIL ME, don't include hate mail, i alread read enough of that here.

[email protected]

shifty_

PS the name 'shifty' was already taken...B..A..$..T//A<>R--D

[PSmonkey]

If you want my opinion. I think people should look into doing something simular to Rice GPU plugin. Yet insted of making textures high res, insted reduce them and convert them into a condence native psp format. This way the RSP emulation wont have to keep trying to convert them when there is a gpu texture cache miss.

This also could go further and tag pc instructions where the texture data is moved from rom to ram then to dmem and just jump over them. That could help improve performance and get mario64 closer to full speed.

[zodttd]

Shifty: Wouldn't it be just as good to let everyone know what method you have in mind, in a way that would explain to developers what you're trying to do?
Worse case is someone does it before you, but credits aside, if your intentions are to see your idea work, then you still get what you want.
The best case would be developers here, and there are some talent on this forum, would help you along with your idea and your methods could be used in future emulator designs if it turns out well...

Basically, why speak of this technique in such vague terms? We don't mind a good technical discussion, especially if it's useful for projects in our field of work.

[Shifty_]

To zodttd

I understand what you are saying, but being dev, new to the psp community, I hadn't realised that everybody could be so defensive, funkman told me that half the ppl didn't even believe it. Well maybe instead of criticizing (i think that's spelt right) they should wait a second for the actual guy who made it to be able to get the stupid confirmation email, that took 2 days

That is why i wanted funkman to release it for me, he didn't have all the details, but he did have some of the details that may apply to what i am aiming for in the final build, which was actually supposed to be the first release.
I hadn't realized that talking in such vague terms was a bad thing, I just want to be able to get it done, and then released, before someone else does. The reason why I left a technical convo was to perhaps get everybody off my back. This is my first major project, and the first release i get criticized.

I know that this can be done, emulation of N64 on PSP at full speed, but this criticism is just telling me, HEY YOU SUCK, SHUT YOUR WHOLE, and stop making ems. It's like they think I'm crazy, you know
like that guy who thought the world was round, and it actually turned out to be. Well, I think that recompiling the rom into memory may be a solution, and may once again get the hype of emulation on the psp up again.

Also, when it is working, I will release teh source, and a technical explanation of what I did. This is a challenge for me, and me alone, that is why source hasn't been released yet. I always enjoy a good challenge!


shifty_

p.s. STFU already, I am trying to do u all a favor.

[Exophase]

Shifty, your post didn't make even a little bit of sense. Fortunately for us, you have to release the source code anyway, so we'll just make sense of that instead, if indeed you changed anything.

I'm now officially waiting.

[Shifty_]

To PSmonkey

I believe that is a possibility, however, I know for a fact that you can have a hi res image, through emulation, through work, and a lot of research and thinking, you can have the same result as playing it on an N64

The reason why they may not do that, I have no clue, you may be on to something

[Shifty_]

HEY EXOPHASE

THAT WAS NOT MEANT TO BE FOR YOUR EYES, NOT ANYONES EYES, FUNKMAN WAS SUPPOSED TO WAIT UNTIL MONDAY, and even then i wasn't sure if it shouldv'e been released, right now, all i did was a quick function that could load in my already edited rom, it will make no difference on your psp okay, I know the rules that i must release the source and that crap, but who cares, one small function, one small change, one thing not meant to be on anyones psp yet, except mine, it is all an accident, please just wait a couple of weeks, i will release the source then, along with the WORKING Deadalus Shifty Beta 2 (it shouldv'e been beta 1 though)

shifty_

[zodttd]

Please make some sense Shifty. I was offering help with your work. What you're saying shows some selfishness and attention seeking. What's worse is like Exophase said, nothing you say makes any sense. How is an image emulated and how does it relate to being the same result of playing it on an N64? I have a feeling you have no clue what you're doing. If you want some help let me know.

[gunntims0103]

To zodttd

I understand what you are saying, but being dev, new to the psp community, I hadn't realised that everybody could be so defensive, funkman told me that half the ppl didn't even believe it. Well maybe instead of criticizing (i think that's spelt right) they should wait a second for the actual guy who made it to be able to get the stupid confirmation email, that took 2 days

That is why i wanted funkman to release it for me, he didn't have all the details, but he did have some of the details that may apply to what i am aiming for in the final build, which was actually supposed to be the first release.
I hadn't realized that talking in such vague terms was a bad thing, I just want to be able to get it done, and then released, before someone else does. The reason why I left a technical convo was to perhaps get everybody off my back. This is my first major project, and the first release i get criticized.

I know that this can be done, emulation of N64 on PSP at full speed, but this criticism is just telling me, HEY YOU SUCK, SHUT YOUR WHOLE, and stop making ems. It's like they think I'm crazy, you know
like that guy who thought the world was round, and it actually turned out to be. Well, I think that recompiling the rom into memory may be a solution, and may once again get the hype of emulation on the psp up again.

Also, when it is working, I will release teh source, and a technical explanation of what I did. This is a challenge for me, and me alone, that is why source hasn't been released yet. I always enjoy a good challenge!


shifty_

p.s. STFU already, I am trying to do u all a favor.

Shifty you must understand that N64 emulation fr the psp has beed anticipated for a while now. For a user to come about and say "hey my friend has a full speed n64 emulator and it will be released soon. Many will be a bit spectical as to this information being real. I myself and waiting for your source as well.

If you are very proficient in C/C++ inprove on the dynarec. I think the one that sttrrrnnnm has in place in an incomplete one or at least a unfinished one. Also you should create some sort of interpreter to increase speed rendering, If possible something in real time that reads and buffers the frameskip rather quickly giving you near full speed. Also would it be possible to have a (JIT) into the code to convert MIP's in real time. If im not mistaken that was exophases approach to gpsp.

I dont know the exact specifications on the n64 hardware to emulate it to the psp so i could be wrong about all of this....

shifty you should accept as much help on this project as you can as i do belive it will be a group effort to get n64 fully emulated with sound and all. No one is trying to steal your credit, I actaully comend you for steping up and taking on this project

[Exophase]

Obviously we care :B

But just because we want to defraud you.

Well, that's the bulk of my motivation anyway.

I guess we'll have to wait a couple weeks either way though.

[zidanerick]

I still say this is crap, you are just ripping off all the hard work that wally and strmnNrmn have done, and you could not have accomplished much because Wally had not released the source of his Spiffy Updates.

[Shifty_]

To everyone on right now

I am sorry for my bluntness, but i did not mean to be rude to you, I was trying to be more focused on the ppl who were giving me bad comments for my work, i'd thought ppl would be happy for what i am trying to do, sorry i hadn't realised that everyone is so defensive here.
About the question before gunntimms,


"If you are very proficient in C/C++ inprove on the dynarec. I think the one that sttrrrnnnm has in place in an incomplete one or at least a unfinished one. Also you should create some sort of interpreter to increase speed rendering, If possible something in real time that reads and buffers the frameskip rather quickly giving you near full speed. Also would it be possible to have a (JIT) into the code to convert MIP's in real time. If im not mistaken that was exophases approach to gpsp.

I dont know the exact specifications on the n64 hardware to emulate it to the psp so i could be wrong about all of this....
"
I am not an expert on N64 hardware either, nor am I as profficient in C/C++ as strrrnnnm, nor am I sure that would be the right path to take for what I want to accopmplish.
I haven't read over the entire deadalus source yet, just some of the bits and peices of it that I may want to work for rewriting a rom file. I think i know what you mean by an interpreter that will increase speed rendering that reads and buffers the frameskip in real time, and you know what, that is going to have nearly the same result of what I had originally intended to do with this. I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games. Perhaps I could take that into consideration. And I am not entirely sure about converting MIPs in real time, as I said before I will take all this into consideration, thank you for your ideas.

shifty_

[gunntims0103]

* Processor: 93.75 MHz NEC VR4300 (info), based on MIPS R4300i-series 64-bit RISC CPU (image)
o L1 cache: 24 KiB (split: 16 KiB instruction, 8 KiB data). No L2 cache.
o Buses: 32-bit address and data.
o CPU to RCP Bandwidth: 250 MiB/s (non-DMA). CPU can not directly access RAM.
o Instruction Set: MIPS R4000 32-bit. Addressable Memory Space: 4 GiB (Virtual 1 TiB).
o 5-stage scalar pipeline. Integrated FPU. 93 million operations per second.
o 4.6 million transistors
o Manufactured by NEC using 0.35 µm process.
* RAM: 4 MiB RDRAM (image) (upgradeable to 8 MiB with 4 MiB Expansion Pak)
o Data path: 9-bit width at 500 MHz
o Potential Memory Bandwidth: 562.5 MiB/s
o ≅640 ns RAM latency
* Graphics: SGI 62.5 MHz 64-bit RCP (Reality Coprocessor) (image) contains two sub-processors:
o RSP (Reality Signal Processor) controls 3D graphics and sound functions
+ MIPS R4000-based 8-bit integer vector processor
+ Programmable through microcode (µcode). Allows functions to be modified or added.
+ Transformation, clipping, lighting, triangle setup, and audio decoding (audio could be done on main CPU as well)
+ Geometry throughput: initially ≅100,000 polygons per second with full quality. Some later games go higher with highly optimized microcode.
o RDP (Reality Drawing Processor) rasterizer handles all pixel drawing operations in hardware, such as:
+ Z-buffering (maintains 3D spatial relationships, is Mario in front of the tree or vice-versa?)
+ Anti-aliasing (smooths jagged lines and edges)
+ Texture mapping (placing images over shapes, for example mapping a face image to a sphere creates head)
# Bilinear filtering (prevents texture blockiness by blurring when resizing)
# Mip-mapping (creates distance textures of varying degrees of fidelity)
# Trilinear mip-map interpolation (filters mip-maps and textures smoothly without blockiness). Nintendo 64's filtering is not entirely accurate. Precision was reduced to lower mathematical demands.[3]
# Perspective-correct texture mapping (keeps textures from "warping" when viewed at different angles)[4]
# Environment mapping (best seen with metal Mario in Super Mario 64)
# Gouraud shading, Level of Detail (LOD)
+ Fillrate: ≅30 megapixels/sec with Z-buffering enabled
o 128-bit internal data bus between RSP and RDP. ≅1.0 GiB/s bandwidth.
o Resolution: 256 × 224 to 640 × 480 pixels flicker-free, interlaced
o Color depth: 16.7 million colors (32,768 on-screen)
* Sound: 16-bit Stereo (usually lower quality). ADPCM, MIDI, Tracker, and MP3. All software-driven by CPU or RSP.
o Channels: 100 PCM (max, 16-24 avg.). Each channel consumes about 1% CPU time.
o Sampling: 48.0 kHz (max, 44.1 kHz is CD quality)
* Media: 32 to 512-MBit (4 to 64 MiB) cartridges
* Dimensions: 10.23 × 7.48 × 2.87 inches (260 × 190 × 73 mm) W×D×H
o Weight: 2.4 lbs (1.1 kg)
* Controller: 1 analog stick; 2 shoulder buttons; one digital cross pad; six face buttons, 'start' button, and one digital trigger.
* Motherboard photo. On the left, under an aluminum heatspreader, is the VR4300 CPU. Right of that is the RCP graphics processor. The lowermost aluminum block covers the pair of RDRAM memory chips. These heatspreaders make contact with a larger heatsink when assembled. There is no fan.

so knowing this now i think it is possible to process MIP's for n64 in real time. At least i think. The psp specification has i think what it takes to emulate n64 at a decent or full speed.

Maybe shifty if you approached n64 emulation by building a emulator from the ground up. That way you know exactly what your dealing with and you will have the leverage to make your own specifications and inplament your own dynarec.

no problem shifty, just putting out ideas as i myself dont know the n64 emulation to psp hardware specifications. I do realize that writting your own emu is extreamly difficult. Also to get a dynarec up is also a hard thing as to what happened to pacmanfan.

[Exophase]

Daedalus already converts N64 MIPS (it's singular everyone. MIPS.) to PSP MIPS and executes it. That's what a dynarec does. A "JIT" is just another (stupid) name for a dynarec.

And no offense, mostly because you're not actually claiming to be an emu dev, but your ideas didn't make any sense either gunntims. But the fact that Shifty actually said they did is pretty bothersome.

Shifty indeed.

[Shifty_]

To:
gunnTim0103

I will look up the specs for the psp and compare, that could be very useful, thanks, I think you may be pointing me in the right direction, except, I don't think I would be able to ever build an emulator as good as deadalus, maybe, like u'd said earlier, a group project. Thank you, i will definitly think hard, over that tonight.

[gunntims0103]

Daedalus already converts N64 MIPS (it's singular everyone. MIPS.) to PSP MIPS and executes it. That's what a dynarec does. A "JIT" is just another (stupid) name for a dynarec.

And no offense, mostly because you're not actually claiming to be an emu dev, but your ideas didn't make any sense either gunntims. But the fact that Shifty actually said they did is pretty bothersome.

Shifty indeed.

of course im not proficient in C/C++ as i cant code a emu myself, just simply giving ideas, as i think shifty has the right ideas

i make no sence :) ....... thanx exophase

no problem shifty :D

[zodttd]

"I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games."

But even your approach doesn't make much sense. What does the ROM have to do with frameskipping? Frameskipping generally referred to a way the *emulator* handles skipping the rendering/blitting of a single frame. For example on the Playstation, in simple terms that disc is pretty much a series of instructions which are read, then "emulated". By "emulating" these instructions, this is accomplished by methods using fancy terms like an interpreter and dynarec. Each of those instructions is processed and determined to be a certain opcode by the bit layout, and then converted to something the target platform (such as the PSP) can understand. All of this takes into consideration different ways of handling input, memory cards, storage, video, audio, etc.

If you edit the ROM you're probably going to see a series of instructions of a certain number of bits. For instance the PS1 is a 32bit platform and uses a 32bit length instruction.

Guessing you aren't changing the instructions, you're probably more concerned with the chunks of data, specifically the textures.

And from what you've said the textures should be converted to a type that the PSP natively understands, such as BGR555. If you go through all the trouble padding the difference in size of the textures, and making some sort of way of processing ROMs to make this easier to do...I have a feeling it won't go much faster. :( ...The textures are converted to a color layout the PSP understands, and then held in a cache (RAM) until the cache gets full and that texture eventually gets kicked out of RAM. If that texture is needed again it gets converted.

Wouldn't it be smart to see how often textures in the cache are being converted more than once, before going through with this?

If they are being converted way too much, it might be a good idea to look at the way the texture cache is handled, and see if you can squeeze more textures into the cache, or go about it a different way.

And if not that, and you do edit each ROM and etc...what does this have to do with frameskipping?

[gunntims0103]

"I see what you mean, because if I just edit the rom to run faster, there will be a constant frameskip, which would be bad for some parts of the games."

But even your approach doesn't make much sense. What does the ROM have to do with frameskipping? Frameskipping generally referred to a way the *emulator* handles skipping the rendering/blitting of a single frame. For example on the Playstation, in simple terms that disc is pretty much a series of instructions which are read, then "emulated". By "emulating" these instructions, this is accomplished by methods using fancy terms like an interpreter and dynarec. Each of those instructions is processed and determined to be a certain opcode by the bit layout, and then converted to something the target platform (such as the PSP) can understand. All of this takes into consideration different ways of handling input, memory cards, storage, video, audio, etc.

If you edit the ROM you're probably going to see a series of instructions of a certain number of bits. For instance the PS1 is a 32bit platform and uses a 32bit length instruction.

Guessing you aren't changing the instructions, you're probably more concerned with the chunks of data, specifically the textures.

And from what you've said the textures should be converted to a type that the PSP natively understands, such as BGR555. If you go through all the trouble padding the difference in size of the textures, and making some sort of way of processing ROMs to make this easier to do...I have a feeling it won't go much faster. :( ...The textures are converted to a color layout the PSP understands, and then held in a cache (RAM) until the cache gets full and that texture eventually gets kicked out of RAM. If that texture is needed again it gets converted.

Wouldn't it be smart to see how often textures in the cache are being converted more than once, before going through with this?

If they are being converted way too much, it might be a good idea to look at the way the texture cache is handled, and see if you can squeeze more textures into the cache, or go about it a different way.

And if not that, and you do edit each ROM and etc...what does this have to do with frameskipping?

would it be possible n64 emulation wise to set up a rom catche that the emulator would read to speed up frameskip. Like in NJ's approach with cps2 emulation. I think this is something shifty "would" have meant if he means editing the rom and code....

i could be wrong

[zodttd]

Unfortunately you're wrong on this one. Your idea of caching the ROM image makes sense. His idea doesn't make sense, and is quite funny in fact!

[gunntims0103]

Unfortunately you're wrong on this one. Your idea of caching the ROM image makes sense. His idea doesn't make sense, and is quite funny in fact!

now im quite confused. What exactly did shifty mean by "i edited the Rom so that it would read faster", did he actually edit a rom file or did he actually edit the code that reads and interprets the rom and emulates it

[PSmonkey]

To PSmonkey

I believe that is a possibility, however, I know for a fact that you can have a hi res image, through emulation, through work, and a lot of research and thinking, you can have the same result as playing it on an N64

The reason why they may not do that, I have no clue, you may be on to something

I am sorry but what you said makes no sense.

A large bottle neck (not the main but definantly waste 2-5 fps for me) in Monkey64 is having to reconvert native n64 textures to RGBA8888 so the psp can render it.

My idea is to take the same concept used by Rice to suport high res textures. Yet insted use it to load pre converted and compressed textures so a sizable chunk could reside in vram (posible if palettised) and make a sizable boost. Now the emu wont have to convert them. Could posibly even remove instructions wasted with getting the data to the rsp. Since the data must go from rom to ram then to dram.

[Exophase]

PSmonkey, don't waste your time, Shifty is 100% clueless.

Here's an amusing log for you all to enjoy. He even gave me permission to post it.

http://exophase.devzero.co.uk/shifty.log

[Accordion]

hee haw

[Zion]

ok this is baen proven fake by exophase and it seems that shifty has no idea what he is doing, avoiding giving any techical details whatsoever.

Im afraid "i editited the rom" just isnt going to cut it.

Fake until proved otherwise.

Locked

[quzar]

You're gonna lock it but leave the download up? What purpose does that serve other than stopping discussion?

[Zion]

whoops, lol. il remove it

[PSmonkey]

PSmonkey, don't waste your time, Shifty is 100% clueless.

Here's an amusing log for you all to enjoy. He even gave me permission to post it.

http://exophase.devzero.co.uk/shifty.log

sorry to spam a closed topic but I just gotta say. Wow. Just wow.