PC Club

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » PC Club » Dreamcast » Makaron - еще один WIP эмуль дрима

Makaron - еще один WIP эмуль дрима

Сообщений 1 страница 20 из 25


Макарон обновился!

So much for me playing Crysis tonight -_-.....anywho, Makaron has a new test release for people to play around with.  Alot of internal changes have taken place inside the emulation core.  Here is the blog post:

Here is Makaron Test 9 for your pleasure. There are lots of internal changes, but nothing revolutionary - so don't expect it to be much better/faster compared to earlier versions. From user point of view, it's almost the same as T8. Quite frankly the only reason I'm releasing it is to test some new stuff inside. For example, it's only thanks to user input that I found the NVidia FX series cards bug so fast (and actually it affected all cards, just that FX couldn't cope with it at all).
There are also people out there who simply have to test anything new that is released, because they love emulating stuff. So this is like a small gift for them, to enjoy for few moments before the novelty wears off :)

Like I said, there are tons of small (and not so small) internal changes to the emulation engine. Some of this stuff is so new it wasn't even tested much yet, so expect bugs. If you find a game that doesn't work now and it used to, please drop me a note - I'd like to find and fix the regressions first.
I won't go into much detail, but here's a list of things I consider interesting enough to explain a bit:

Dynamic Z-buffer range compression
This is a new method of dealing with overblown Z/W values. Most of the work is done in vertex shader so there should be no noticable speed impact. I mean, if there is then your graphics card was too slow to begin with and this is just another drop in the bucket.
Now I can handle geometry more like PVR2 does, which is good because this allows proper shadow casting. Very much like NANs, infinities are now detected and handled CPU-side - so far it appears to work as expected. All this and no Z-precision issuses, not that I'm aware of at least. Unless there's a game out there making a real use of 32-bit floating point HDR in Z-buffer this might just be THE solution :)
Note: There are games that still do not render properly due to other bugs, also this does nothing to cure transparency/ordering problems.

Shader Model 2 is now default
Makaron will now use VS 2.0 and PS 2.x (x being 0, a or b - where available), and fall back to 1.1/1.4 if it has to. What's more, I might be dropping SM1 support sometime in future. There are so many problems with it... I've had VS 1.1 break geometry which VS 2.0 handled just fine. And let me remind you again that palletized textures filtering is disabled on PS 1.4 beacuse it's too primitive for that kind of processing.
It's also about features that older cards do not have - like multiple render targets, or floating-point type surfaces. The Z compression code is considerably shorter compiled for 2.0 profile than it is for 1.1 by the way. Funny thing though, even if SM3 code is shorter it actually executes slower on most cards. That and the bugs I found in the drivers made me choose SM2 as the best perfomer.

Texture caching fixed
At least I hope it is :) Makaron MT version should no longer crash so much or trash textures. That does mean the single-threaded version will be a bit slower though - it's a tradeoff I've made to allow for proper locking. Some bugs still remain, mostly to be seen in Soul Calibur, but that's another story.

Shadows now work
Well, most of the time, and so are enabled by default. There are several ways it can be done - so far I was unable to come up with one method capable of handling all cases. Maybe there isn't one... Well, for now you can switch between different algorithms - you'll need to do that for Crazy Taxi series at least.

You really should be using multiple-core system for Makaron, mind you - this is the target PC I'm aiming for. SH4 speed is very important, but once you can do rendering in parallel most games will happily run full-speed on as little as 70-100MIPS. Seeing as AthlonXP clocked at 2000MHz is just below the required minimum, I'd say any mid-level X2 or C2D system will do fine.

The known bugs you will surely ecounter are mostly in AICA (sound module) code. The volume levels are still wrong - not sure why, I made the tables up to the specs. And yet PCM range often exceeds 16-bit, causing major distortions even if clipped. Also, ARM speed has been reduced to 1.5MIPS - this should make Soul Reaver happy. This is not exactly correct either, and will probably break some other games... I'll keep looking for a better solution.

As usuall, if there are any silly-yet-critical bugs discovered, I'll fix them right away. Other ones will have to wait for next "major" release :P

WARNING! Be careful not to overwrite your VMU or INI files when moving to T9!



С 25 февраля стала доступна новая версия Макарона - T9/2.
Это бета версия, она принесла много нововведений/улучшений, и конечно, багов :) Автор позиционирует ее как - "Хочу узнать на сколько она баговая и как часто будет падать."

Нововведения примерно следующие (пишу по памяти после прочтения всего блога автора):
- обновлен AICA (избавился от DSP и улучшен звук)
- обновлен GD-reader (улучшена скорость и исправлены некоторые ошибки)
- добавлен recompiler MMU, позволяющий запускать игры, которые должны работать из под WinCE ( - ОС'ь дрима )
- много других улучшений и исправлений...


Блин,вместо того чтобы запускаться, макарон просит BIOS_USA.bin :O    Откуда его откапать?


Качаешь сборку Фокса с NullDC - http://depositfiles.com/files/2449803. Там будут оба файла в архиве, в папке data. Их надо переименовать соответствующим образом. Тот что Boot - на BIos_usa, тот что флэш - на что-то еще :) . Щас посмотрю. Но думаю сам разберешься.


Автор макарона - Deunan опубликовал очередной отчет развития своего проекта.
Пока неизвестно о дате выхода новой версии эмулятора.
После релиза T9/2 это уже третий отчет об изменениях.


Приятно слышать :) . А какой кстати минимальный размер игрушек для дрима? Хотелось бы хоть что-то утянуть, хотя с 300 метрами на месяц врядли что выйдет :D


Новая порция скринов от Deunan
На этот раз ничего не исправлено и не изменено, автор просто проверял игры которые имеет и решил поделится впечатлениями и скриншотами.

Фиг их знает :) У меня есть Shenmue обе и Sonic adv2. Каждый диск по 700-800 метров... Если найти какую-нить 2D игру, то она занимать будет, наверное, меньше... :)


Я достал WWF (не пожалел 150 метров, блин, 3.5 бакса мне со счета! :( ). Эмулиться норм на nullDC (мот выложу скрины потом), а Makaron в первый раз запустил, не понял работает ли он с mdf образами. Сегодня посмотрю.


народ, обращаюсь к вам, как к людям зающим. я скачал себе образ dead or alive 2. формат  cdi. запускал на NullDC_v1.0.0_Beta_v1.6
скорость выдавал этот эмуль около 30 vps . как я понимаю, для нормальной игры надо раза в 2 больше как миинмум. почитал вашу тему про новую версию макароны. скачал. сложил в нее биос и флэш, как надо переименовал. при запуске макаронина выдает слюдующий крит

<Directinput error> (-1104)in module Makaron: WinMain - Makaron.Uruchom -> HOLLY.Uruchom -> HOLLY/Maple.Uruchon -> HOLLY/Maple.UruchomWtyczki -> (Makaron controller).Uruchon

подскажите пжалста как это вылечить. и стоит ли это лечить? (будет ли на этом эмуле в DoA2 нормальная скорость)
надеюсь на вас, а то я уже дней восемь с этой игрушкой ковыряюсь...


Эта ошибка говорит, что джойстик не настроен.
1) Чтобы пользоваться макароном обязательно нужен джойстик. И  Deunan сказал, что поддержки клавы не будет.  {>_<}
2) Открываем Makaron.ini, находим там "PADcfg = 0" и 0 заменяем на 1. Запускаем макарон и настраиваем джойстик. У меня его нет, поэтому я дальше не продвинулся :)

Кстати, Dragonheart, Deunan в readme к макарону пишет о mmu следующее:

makaron readme написал(а):

Windows CE based games will work only with MMU enabled. This requires pretty fast CPU to be anywhere near playable.
MMU support will be automaticaly enabled for known games that require it, but you may need to manually override this in the configuration file.

Т.е. mmu версия нужна для WinCE игр.


мде... джой настроил. благо он полностью аппаратный и проблем не возникло. 
щаз ДоФ2 запустился. но идет как и на других эмуляторах в полскорости, да еще плюсом две зеленые полоски какие то появились. но это не важно... скажите половинная скорость лечится или мне забросить затею?
сол калибур не запустился впринцыпе. после дримовской заставки кидает обратно в биос. жму играть - обратно в биос и т.д. теперь точно спать.......

Отредактировано Роман (2008-03-23 04:39:29)


А что у тебя за машина? У меня все игры для дрима летают, при всей бюджетности моей машины...


У мя ток одна гама, но там фулспид :) . В nullDC в 1600х1200 (все настройки графы - последние значения, т.е. можно еще больше скорость выжать, если вставить например Sort - Fast значение, т.е. первое и т.д.). Конфа тута расписанна - тыц.


AMD Athlon 1,92ГГц \ 1Гб оперативки \ видео radeon9600 128mb... мать не помню какая


ну дык оно и ясно тогда :D . ЦП - XP, да? Попробуй если только underflock cpu активировать в nullDC. иначе только апгрейд/недецкий разгон. Утилитка Hare то ж может помочь ;)


Новые новости от Deunan

Time off
I knew there was a good reason for not touching the GD-ROM code. But I did, and as it stands now it's pretty broken - I will need to redesign it quite a bit.
There are several major problems to solve, all tied to multithreading. Unfortunately I don't really know how to fix them. Or rather, I do, just haven't come up with an idea I feel like implementing. I'd rather spend some time thinking about it and do it right (well, mostly) than throw a ton of nasty patches in. I might actually have to pull out a drawing block, some pencils, and start designing it on paper first. This is a bit new to me, not being able to easily cover for all possible cases in my head. I guess that's MT for you...

I hope to release something in the first week of April. If the new GD code is not ready by then, I'll revert to the old one. I want to see if vibration works for other people too. By the way, I haven't done a single thing during holidays :) I blame Knurek. And Shin Megami Tensei: Lucifer's Call he told me about. But mostly Knurek.

В кратце, он взялся за переделку кода GD-ROM. Пока получилось только сломать его :)
Вначале апреля (первую неделю) стоит ждать еще одного выпуска. Будет это очередной бэтой или полноценным релизом, не уточняется. Автор сомневается что к этому времени успеет доделать GD-ROM, поэтому просто пихнет старый.


Вышла версия Makaron Test 9/4.

Deunan написал(а):

Originally I intended to "disappear" for a week (just like last time) and have my fun reading the comments, hate mail and cursing. Unfortunately not that many sites picked up on this idea of mine and so I'll have to cut it short. Pity.

I especially enjoyed the threats to move to another emulator. How silly is that? Folks, you're free to do that anytime you want and you don't need my permission. Really.
Let's face it - most of you got angry because you took free Makaron for granted and now I was about to take it away from you. You got all cozy thinking you somehow deserve it. Well... think again.

Having said that - hook, line AND SINKER, people :)

UPDATE: Makaron Test 9/4 for those who like to experiment.
I'd urge you to wait for T10 as this is a bastard mix of current (broken) dev and older T9/2. I got it to compile and run but that's about it - not tested. It does include the DMA changes that should make WinCE games more stable but I make no guarantees.
It's still using old GD code which means (with the DMA changes I've made) it will most likely break Street Fighter Alpha and some other games.
Use the supplied plugins and Maple.ini to get vibration support and use F12 menu to enable VMU LCD overlay. Also, make sure to change sorting mode because it defaults to "Alternate" which turned out not to work for some games.
This release goes beyond experimental, it's downright partisan :) I'm not kiding you - unless you like 'em rough stay clear. I'd like to have some feedback on vibration support for upcoming T10 and that's the only reason it exists.

PS. No changes to full-screen mode in this one, and no support for 16:X aspect ratios. And Yuki, stick to your T9/3 for now :)

UPDATE 2: Okay people, here's what you need to have vibration:
1) T9/3 or T9/4 Makaron executable
2) T9/5 or T9/6 MakaronPAD.dll
3) Maple.ini edited so that MakaronPAD is being loaded instead of MakaronVMU for Slot 1 or Slot 2 on given port
4) Gamepad capable of vibration
5) Game with PuruPuru Pack support (you might still need to enable it in game options)

If you can't get T9/4 to run at all with supplied Maple.ini (crashes with an error), but it does work if you modify it to have VMU (or nothing) instead of MakaronPAD in the Slot1/2, it's a problem with my code not doing the right thing with your pad. Another easy way to check is to use Maple.ini (and plugins too if nothing else helps) from T9/2.
If it does run but you get no FF effects it could be the game doesn't use it or needs to have it enabled first. If you're positive everything is as it should be, it's probably my code again. A fast way to test if the plugin is loaded as it should be:

HOLLY/Maple: 0x20: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x01: Makaron VMU (0x00030201 / 0x00540904)
HOLLY/Maple: 0x02: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x60: Makaron controller (0x00270101 / 0x00540905)
HOLLY/Maple: 0x41: Makaron VMU (0x00030201 / 0x00540904)
HOLLY/Maple: 0x42: Makaron VMU (0x00030201 / 0x00540904)

See, the 0x02 address of port A is using PAD plugin instead of VMU.
BTW, don't try to be too smart and have 2 VMUs and a PuruPuru Pack together. Though it's possible to assign addresses 0x04, 0x08 and 0x10, no real Dreamcast device has more then 2 slots and most games will not recognize such configuration. You can try your luck with homebrew KOS/Linux/BSD software, those usually don't have such limitations.
For those of you who never had a DC controller in their hands - PPP will fit in Slot 1 but it's big and will prevent you from using VMU in Slot 2. Not to mention only Slot 1 VMU LCD is visible (in Makaron too) so it's best to stick PPP into Slot 2.

And another thing - you'd be suprised how broken gamepad drivers can be. I've got two and each had it's nasty suprises (and I've yet to try PS2 Dualshock USB interface). Also, force feedback features can vary from very basic "rumble" ones to a real force working against your moves. It's not that simple to get those more complicated gamepads to do simple vibration it seems...


А дела тем временем движутся:

I've finally completed the new GD-ROM module, though ultimately it turned out to be very similar in design to the last one. With the new code I can freely choose what ATA/ATAPI commands are to be executed immediately and what can be offloaded to helper thread.
Unfortunately a thread is not a very good substitute for a real-time device. In typical multitasking OS there's a sheduler that decides when things will happen, there's no guarantee that the helper will start processing given request right away. Simply put, it can start immediately or only after some tens of miliseconds has passed. I could run the code in a tight loop to reduce this lag but that would waste too much CPU power, always needed elsewhere. Not to mention OS can (and eventually will at some point) interrupt any running process if it's required, so this approach would not solve the problem completly, just reduce the odds of ecountering it. Same thing goes for messing with thread priorities - that's not exactly foolproof and is also very inelegant.

Now, why would mere miliseconds ever pose a problem? In a well-designed system the consumer would just wait a bit for the producer to come up with data and occasional lag wouldn't even be noticable. Some Dreamcast software however (BIOS including) doesn't really check if the data has arrived, rather assume it must be so after a certain amount of time has passed.
This isn't that much of a problem for GD-ROM commands that return small amounts of redily available data - those can be simply executed at the moment they arrive, so there is no lag. Disk reads are another story though, those take time to complete and the whole idea was to run them concurrently so that virtual CPU would not be stalled waiting in the first place.

It gets more interesting at this point. A real Dreamcast GD is not anywhere near as fast as modern hard drives, so why doesn't it work in emulator if it works on an inferior system? The answer, again, is timing. It's simply very crucial to get it right - and you can have accurate emulator, or fast emulator, but not both. And you've guessed it right, I'm aiming for fast at this point. It has to be noted that should the original GD/CD media become too scratched or the laser detoriates beyond certain point, the problems I'm having will manifest themselves on Dreamcast as well - so I still say it's simply bad coding on games part.
What are the options... For starters, I will continue to play with the DMA code and try to mimic Dreamcast behaviour as closely as possible. And if all else fails, there's still the "ideal" DMA mode, that is to make transfers always block to be sure the virtual CPU always gets all the data it asks for. This of course causes jerkiness and audio stuttering, mostly to be felt in games using sequenced music or sound effects very closely timed to video.

This whole re-write took quite some time and didn't really help as much I hoped, but thanks to all that work I'm now much more aware of what has to be done yet. I've a few ideas, it's just that every attempt at fixing one thing breaks other stuff. Sometimes very badly :) I still need to figure out what upsets so much the MPEG library used on demo GDs and some MIL-CDs.

PS. Why didn't anyone tell me Giana's Return got broken with the addition of MMU-capable recompiler?!
PPS. I'm SOOO behing with testing Yuki's stuff now... I'm going to capture & post few screenshots later today. If I get the games to work with the new GD code that is :)

No screens yet. I had a bug that prevented most of the images from booting properly, that's fixed now. But there's a bigger problem - the new module is actually even less compatible, timing-wise, than the old one. I'll have to run more tests but now I'm beginning to suspect that some games require GD DMA processing to be done way more often. Which is bad because it seriously affects emulation speed.
At this point one begins to wonder what exactly is good about this new code :) Well, it is more reliable now. I was hoping that alone would be enough but apparently I was too optimistic...

A bit closer, still not there.


This is starting to seriously annoy me. DMA changes helped with some tiles but not all of them. Then I inserted a few debug statements into the code and even though it reduced emulation speed, it actually made things more stable. And this is the only lead I have so far...



Очередная порция скринов от автора Макарона. Он исправил баг нового кода GD. Некоторые игры не грузились с новым кодом.


Вышла версия Т10!!

"I think I've finally got the DMA code working. Well, for me at least  It needs to be tested further on variety of hardware - and that's where you people come in. Expect T10 soon.

Some loose thoughts I feel like voicing:

1) T10 might be a bit slower than T9 series. It'll most likely affect only low-end systems as there isn't really much of a difference (if any) on my E6600.
2) WinCE games usually crash when emulation speed drops below certain treshold. In other words, if you got fast system you should get stable performance.
3) Due to changes in GD-DMA code loading times are back. It's considered normal behaviour since this is how Dreamcast works. Thanks to those changes compatibility has improved and following titles should now boot and work:
- all Dream Preview discs
- original MIL-CDs
- Street Fighter Zero 3
- SEGA Tetris Online
- Tetris 4D
4) CD-DA (audio tracks) will play, but still use the older method of fetching data. This might cause Makaron to crash but it's very unlikely as data reads and playing audio are mutualy exclusive tasks.
5) There are some minor changes in full-screen setup code (the debug window will be hidden and not forcibly refreshed). No 16:x aspect ratios yet.
6) Changes to sorting/drawing code broke shadows in Virtua Fighter 3tb. I'm not planning on fixing that anytime soon though, as it would break many other things. Late T9 versions have this problem too, by the way.
7) Makaron now disables screen saver when run. It's only going to be a problem if it crashes, as it might not re-enable it on exit. Just so you know.
8) If you manually enable MMU the recompiler will not switch to address translation mode until it's actually requested, so there's no speed penalty in BIOS and most games. Some however (like Ikaruga) use only partial translation and this can be emulated without full-blown MMU support. It'll work either way but will be a lot slower with MMU enabled. Some WinCE games are automatically recognized (this works only for GD images) and MMU will be turned on when necessary. In short: keep it off unless Makaron complains about it.

UPDATE: Few more notes:

There were some last-minute cleanups in the code, I hope I didn't break anything
MT version is the one I actively develp, the other is just dumbed down not to support threading. Not tested much so your mileage may vary.
As always, make sure you backup your own INI files if you want to keep them. For GDROM.ini though you should comment out the GDMT setting, or choose one of the following:
-1 is immediate mode. This will block emulator and allow the read to complete. In short: worst performance, but should always work. This is also the default mode for non-MT version.
0 is deffered mode. The read still blocks, just not right away but rather outside SH4 main loop. It might provide smoother emulation (if it works at all
1 is threaded mode. Disk reads are scheduled to separate thread for another core/CPU to take care of. Best speed, smooth emulation, should now work with every game. This is the default for MT version.
Threaded mode can't be selected for non-MT version of Makaron - deffered method will be used instead. This limitation was introduced on purpose, and might be lifted in future. Note that unless you have multiple cores/CPUs it will work just like deffered mode anyway.

I'd also like to remind you that there's a frontend to Makaron called mkfro. Highly recommended for people who can't work my INI files.

Anyway, click here to download Makaron T10.

UPDATE2: If you experience random crashes while in-game movies play (or are about to start), or from time to time CD/GD image refuses to boot (but works most of the time) - report this. Give me the title and your PC specs."

Скачать (с рапиды)

Вы здесь » PC Club » Dreamcast » Makaron - еще один WIP эмуль дрима