|
|
Search
|
|||||||
| Home | Register | Downloads | FAQ | Members List | Calendar | Arcade | Mark Forums Read |
![]() |
|
|
LinkBack | Thread Tools | Display Modes |
|
|
#21 (permalink) | |
|
Banned
Join Date: Oct 2009
Location: somewhere
Posts: 42
|
Quote:
|
|
|
|
|
| Advertisement | [Remove Advertisement] | ||
|
|
|
|
#23 (permalink) | |
|
Banned
Join Date: Oct 2009
Location: somewhere
Posts: 42
|
Quote:
|
|
|
|
|
|
|
#24 (permalink) | |
|
Emu author
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Apr 2001
Location: Cleveland OH, USA
Posts: 1,184
|
Quote:
Last edited by Exophase; October 8th, 2009 at 15:49.. |
|
|
|
|
|
|
#25 (permalink) | |
|
Emu author
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Nov 2002
Location: Austria (originally from Dominican Republic)
Posts: 2,380
|
Quote:
...mmmm no comment
__________________
Current development tools: Visual C++.net, Visual C#.net Visual VB.net, Visual Webdeveloper.net Bloodshed Dev C++, Borland C++ Visual Basic 6 Last edited by @ruantec; October 8th, 2009 at 16:39.. |
|
|
|
|
|
|
#26 (permalink) | |
|
You're already dead...
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2007
Location: Post-Apocalyptic Earth
Posts: 3,904
|
oh well, seems ![]() but of course he managed to kill another one of the few threads i create in this section, so i guess he accomplished what he set out to do...
__________________
Quote:
check out my blog ![]() |
|
|
|
|
|
|
#27 (permalink) |
|
Hackin 'n Slashin
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jan 2007
Location: Corrupt Rapist run South Africa
Posts: 11,327
|
sorry about that cotton, he just despises you and can't see that you've grown immensely since the days when you were just a beginner hacking at PCSX2 code to try and make it faster when he made the decision you're no good (remember similarily to you he considers coding an absolute art form). It's actually ironic how much you two fight considering how similar both your belief structures are when it comes to coding and how passionately you both believe in them. If not for erroneous judgements made in haste at the start you could and in fact should be best of friends.
__________________
Intel Core2Quad Q9550 (2.83Ghz stock) | ASUS P5Q | 2x2GB Transcend JetRam DDR2-800 | ASUS ENGTX260\HDTP\896M | Windows Vista Home Premium 64bit SP1 The Champ has retired but may his Legacy live on FOREVER !!!! Get it right fools! The glass is HALF-EMPTY, not half-full!!! !!! WARNING: Emulation requires a brain !!! WARNING: Emulation =/= Piracy !!!
Last edited by SCHUMI_4EVER; October 8th, 2009 at 21:21.. |
|
|
|
|
|
#28 (permalink) | |||
|
You're already dead...
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2007
Location: Post-Apocalyptic Earth
Posts: 3,904
|
Quote:
my beliefs in coding are something like: 1) optimization is about the end-result speed 2) clean code is sometimes better than optimization (you generally have to weigh the speed-benefit VS the code 'ugliness') 3) my favorite optimizations are ones which are faster, simpler, and cleaner. i assume mud's is something like: 1) file size and memory foot print matter most. 2) un-needed features should be stripped out to make the footprint smaller. most of the time file size has no correlation to program execution speed (except in different extreme cases which i'm too lazy to describe), so i personally don't care if a program is 64kb vs 3mb (except the smaller file size is preferred if it does everything and looks exactly the same as the the larger program)... and memory footprint also has no real correlation to speed. so i only care about the program taking a reasonable amount of memory for its given task. there's many-many cases where you come across great optimizations that will increase speed a lot, but it will increase allocated memory and file size. putting a limit on filesize and memory footprint is essentially limiting your program. and i don't believe in limiting my programs for seemingly no valid reason (only things i can think of are bragging rights or proof-of-concept). furthermore, setting limits on memory usage is effectively refusing to evolve on programming. as one of my programming instructors once said: "as technology increases and gets more powerful, programmers are expected to do greater things and work with more data." (or something like that) Quote:
furthermore i've seen mud constantly flame even his closer friends when he gets angry. so i personally wouldn't want to be friends with someone like that... even if our interests were 99% similar. ideally i get along with kind people who are open to new ideas, and if the idea isn't good they logically explain why they think it isn't. and if we disagree on something we just agree to disagree; not start flaming ;p life is too depressing to have even your friends yelling at you ![]() in that case its better to have no friends at all... anyways i guess i sidetracked this thread; but the initial conversation died anyways so not like it matters anymore
__________________
Quote:
check out my blog ![]() |
|||
|
|
|
|
|
#29 (permalink) |
|
Hackin 'n Slashin
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Jan 2007
Location: Corrupt Rapist run South Africa
Posts: 11,327
|
well I would say you got a fair bit out of it and if you can coax exophase back you can get some more, but yeah sorry about that again. Mud has no sense of moderation, there's only 0% and 100%, nothing unbetween, he can't be moderately upset it's just full on rage mode as soon as even the smallest thing upsets him in the smallest manner.
__________________
Intel Core2Quad Q9550 (2.83Ghz stock) | ASUS P5Q | 2x2GB Transcend JetRam DDR2-800 | ASUS ENGTX260\HDTP\896M | Windows Vista Home Premium 64bit SP1 The Champ has retired but may his Legacy live on FOREVER !!!! Get it right fools! The glass is HALF-EMPTY, not half-full!!! !!! WARNING: Emulation requires a brain !!! WARNING: Emulation =/= Piracy !!!
|
|
|
|
|
|
#30 (permalink) | |||
|
Emu author
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Nov 2002
Location: Austria (originally from Dominican Republic)
Posts: 2,380
|
Optimization cotton is a great part of programming.. of course there are many different views on that.. i by myself am not much different than Mudlord in that area but the main difference between us is that i make exceptions when it comes to graphics design and memory/size usage... sometimes when you care about optimizations and size you find out bugs/problems you probably skip if you donīt take those points in mind ![]() Quote:
![]() either way i think you have a great point there Quote:
now talking about killing threads... you and Exophase killed my "no comment" thread and few others i rarely create here remember??? thatīs actually the reason why i got mad/pissed a while ago because you guys kept killing every single thread i opened.. but i guess/hope it wasnīt intentionally. ![]() Quote:
so mudīs style is passive against his ![]() Spoiler:
__________________
Current development tools: Visual C++.net, Visual C#.net Visual VB.net, Visual Webdeveloper.net Bloodshed Dev C++, Borland C++ Visual Basic 6 Last edited by @ruantec; October 9th, 2009 at 10:02.. |
|||
|
|
|
|
|
#31 (permalink) |
|
Emu author
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Apr 2001
Location: Cleveland OH, USA
Posts: 1,184
|
A lot of performance optimizations actually come at the expense of space. Especially for emulators, you usually won't have the fastest code unless you expand a lot of path combinations. And then on the data side there are look up tables. Of course, higher code/data footprint could come at the cost of inferior cache performance, but it's a common misbelief that one always results in the other. You can have a large set range without having a large working set. You might have 1MB of code but the program only actively uses 5KB of it most of the time (but you can't determine which of that 5KB it's using since it varies per instance). Or there might be a 16MB look up table but the top 15.9MB are only touched in abnormal situations, or maybe only the first 1KB of every 1MB. Might sound strange but I find things like that all the time. So I find it kind of weird when someone wants to maximize both size and time performance, it's just usually not possible to get the best of both. I think mudlord's irritation is due to all of the programs that are both slow and way too bloated at that. Personally I think it's silly and irritating that I need at least 2GB of RAM to run a Linux desktop that's doing little more than a desktop 5 years ago would be (that certainly didn't need so much RAM) and even then it still runs chuggier now. Problem is that, like said, mudlord seems to go to extreme extents on these thinss. |
|
|
|
|
|
#32 (permalink) | |
|
Emu author
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2007
Location: idk
Posts: 251
|
Quote:
I have worked on, well, the Snes Emulator for PSP, but never attempted my own emulator. One day soon I shall start ![]() Keep it up! |
|
|
|
|
|
|
#33 (permalink) | |
|
You're already dead...
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2007
Location: Post-Apocalyptic Earth
Posts: 3,904
|
heh well as an update, for now i've abandoned the dynarec idea to focus on emulation accuracy and getting things to work (might come back to it once things are working correctly). My goal now is to make a good nes emu with good emulation accuracy and cool features, but w/o a lot of unnecessary bloat. Something not as bloated as nestopia, but ideally more around the lines of Jnes with cooler features. Simplicity is also a goal, you shouldn't need to read any tutorials on how to setup a nes emu ^^ Also from a source-code perspective, portability is not a goal. The emu is intended just for windows OS's, and i dont' want to bloat the code supporting other OS's and compilers... As an emu update, currently 95% of mapper0 (no-mapper) games show stuff (the others just show a grey screen). Stuff like donkey kong are playable, but not working 100% correctly (probably some cpu bug). I don't have any other mappers implemented yet, but i probably will soon cuz i'm getting bored of testing the same mapper0 games over and over xD I have savestates working, and wrote a HW accelerated directx9 renderer (was using StretchDIBits() before, which was un-HW accelerated and slow ^^) I've threaded the emulation so it runs on a seperate thread from the GUI (which is nice since emulation continues while processing gui events; such as dragging the window around) i also rewrote my ppu to be cycle/pixel accurate, instead of updating every scanline. sadly I've slowed down the emu from max 600fps to now 120fps on my pc, but i will work on optimizations later... my goal is at least ~300fps for me to be content with the speed.
__________________
Quote:
check out my blog ![]() |
|
|
|
|
|
|
#34 (permalink) | ||
|
You're already dead...
![]() ![]() ![]() ![]() ![]() ![]() ![]() ![]() Join Date: Sep 2007
Location: Post-Apocalyptic Earth
Posts: 3,904
|
Quote:
![]() oh also, the numbers beside the fps in the titlebar are 'frames recorded'. my emu has the ability to rewind emulation (i think nestopia and retrocopy can do that too). its very cool dieing in the game, and then rewinding time before you died ^^
__________________
Quote:
check out my blog ![]() |
||
|
|
|
![]() |
| Thread Tools | |
| Display Modes | |
|
|