Showing posts with label Xbox1. Show all posts
Showing posts with label Xbox1. Show all posts

Sunday, July 12, 2015

More XQEMU Progress!

Once again, I dare not take credit for most of these (nor would I take full credit for what I did fix), but I spent my Saturday afternoon fooling around with XQEMU, and this is what I managed to do/discover.  I noticed a missing/broken feature or two in the code today, so I went in there, and fixed 'em to the best of my ability.  What happened?  I ended up getting Namco Museum ingame, and Panzer Dragoon 1 is now playable.

I took a video of these two games in action.



JayFoxRox informed me that he fixed the flipping issue that's been going on in some games like Namco Museum.  Not 100% sure what the issue with Panzer Dragoon is, but for now, just enjoy the feeling of playing this game on acid!

Also, I've got to admit, this emulator is progressing much faster than Cxbx has, and the compat list is growing rather fast.  I tested and tinkered with a handful of other games, and I'll update my compat list later because it's 4am, and I'm tired.... and yes, I tried JSRF, it doesn't work yet.

Well, that was a weekend well spent.  Good night everyone.

Shogun.

Tuesday, June 30, 2015

Someone is Stealing my Identity!

Okay, this is pretty outrageous.  Who the hell would go this far as to impersonate me on reddit?  Wtf?  Yes, you heard right, someone is pretending to be me, don't be fooled...

Thanks to yun-daddy, I caught wind of this yesterday (maybe he did it, lol).  I didn't get around to reading it before because I was busy (yes, I was actually working on Cxbx for a change), so I had initially assumed someone was making a post in my honour or wanted to inquire about my past work.  Turns out that was not the case.  I should have investigated before things snowballed into what it is now.

Link: http://www.reddit.com/r/emulation/comments/3bhisz/blueshogun96_here_author_of_the_original_xbox/

For those of you who want proof that this is fake, consider these.
  1. I haven't been going to school at all.  In fact, I haven't set foot in a university since 2007.
  2. I stated that I don't have a job earlier on my blog.  Btw, for those of you who were wondering how my interview with 343 went, I didn't get the job because they wanted a more experienced C# dev.
  3. When I make announcements or just want to speak my thoughts on Cxbx, I do it here first, then link it other places.  In fact, I've never had a reddit account in my life until today (and my nickname there is "real_blueshogun96").
  4. When did I EVER claim to be the author of Cxbx or XQEMU?  Never.... Not.  Even.  Once.  These were originally written by Caustik and espes, respectively.
  5. I never even stated that I would have a definite means of working on Cxbx.  My retro gaming PC which I mentioned yesterday isn't truly ideal to work on it.  XQEMU is another story though, but I'd like to work on getting the setup working on my Mac Pro aside my Macbook.
  6. His impersonation of me is terrible.  I sign my statements as "Shogun", I never refer to my favourite console as "OG Xbox" because there's nothing "Original Gangsta" about Xbox.  Lol, I had to make some fun out of this.
 Looking on the bright side, I must really be special if someone is going out of their way to impersonate me of all emu devs.  Besides, they say it pays to advertise!  But in the mean time, I'm going to start another reddit post regarding this imposter as well as link back to this blog post as proof.

So, now that you are aware of all this, don't be fooled.

Shogun.

Got Cxbx running on my retro gaming PC

This evening, I fired up my old Dell B1000r because I needed a 32-bit machine running Windows XP for a few tasks.  Then I thought to myself "I wonder if I can run Cxbx on this old thing...".  Surprisingly, it worked!  The specs: Pentium III 1Ghz, GeForce 5200 (AGP), and 384mb Ram.  Although I didn't have much on the hard drive, I did get to play around a little bit.


That's a screenshot of the intro video of Innocent Tears (Japan only; XDK 4627).  Now, I will be honest and say that I did alter this screenshot a bit.  The intro video only runs at half the normal size when the YUV overlay is converted to RGB via software.  Using hardware accelerated YUV overlays fixes the problem, but then you can't take screenshots of it because YUV surfaces can't be screen grabbed normally on XP, so I just stretched the image.  Btw, just in case you are wondering why I never gave updates on this game before, I had reached a blocking issue when trying to get this title ingame.  Honestly, I can't remember what it was either. For those who want to see the intro video in action, I've uploaded the video on Youtube (I'm surprised no one has done this before).



I didn't have any of the games I knew were playable on this machine, so I couldn't verify by playing Turok, Smashing Drive, Whacked, Robotech BattleCry, etc.  Next time, when it's not in use, I'll hook up my old Seagate HDD that contains most of my dumped games, see if Turok runs at playable speeds, lol.  I know Robotech won't since I had a hard time getting 20fps out of that game on more advanced hardware.

Although Cxbx runs on this ancient gaming PC that once cost $2700 usd, I dunno if I could actually use it to work on updates for it.  Doesn't hurt to try, of course.  If only that thing didn't generate so much heat though.  It's summer time, and my apartment doesn't have AC either :(

Just thought I'd give you all an update since I *might* have a means to work on this again.  Not a solid guarantee, but I'll investigate later.  Until next time.

Shogun.

Tuesday, June 10, 2014

XQEMU Compatibility List (Updated July 21, 2015)

Okay, I've gotten a few requests/inquiries for XQEMU's compatibility, so I'm going to write and maintain a compatibility list.  Personally, I'd like to keep it focused on commercial games right now.

The following is a representation of progress made with all 3 major branches between espes, JayFoxRox, and myself.

IF IT'S NOT ON THE LIST, THEN IT'S LIKELY UNTESTED!  I CAN'T STRESS THIS ENOUGH!

Total Games: 58
Playable: 2
Ingame: 11
Menus: 14
Intros: 16
Nothing: 15


1. 4x4 Evo 2
Status: (Ingame) (*)

2. AMF Bowling
Status: (Intros) (**)

3. Conker: Live and Reloaded (Demo)
Status: (Intros)

4. Dave Mirra Freestyle BMX (Demo)
Status: (Intros)

5. Forza (Demo)
Status: (Intros) (**)

6. Rollercoaster Tycoon
Status: (Menus) (**)

7. Smashing Drive
Status: (Playable)

8. Sonic Heroes (E3 Demo)
Status: (Ingame) (*)

9. Tony Hawk's Pro Skater 2X (Demo)
Status: (Intros)?

10. Wreckless: The Yakuza Missions (Demo)
Status: (Ingame) (*)

11. Jet Set Radio Future
Status: (Intros)

12. Panzer Dragoon
Status: (Playable) (*)

13. Panzer Dragoon ORTA
Status: (Menus)

14. Antz
Status: (Ingame) (*)

15. Aquaman
Status: (Ingame) (*)

16. Apex
Status: (Nothing)

17. Azurik: Rize of Perathia!
Status: (Menus)

18. Blinx
Status: (Nothing)

19. Broken Sword
Status: (Nothing)

20. Brute Force
Status: (Intros)

21. Castlevania: Curse of Darkness
Status: (Nothing)

22. Cel Damage
Status: (Menus)

23. Conflict Vietnam
Status: (Menus)

24. Crazy Taxi III
Status: (Ingame)

25. DaiSenryaku
Status: (Nothing)

26. Dead to Rights
Status: (Intros)

27. DeusEx
Status: (Intros)

28. Dead or Alive 3
Status: (Nothing) (***)

29. Dead or Alive Xtreme Beach Volleyball
Status: (Nothing) (***)

30. Dragon's Lair 3D
Status: (Nothing)

31. Dynasty Warriors 3
Status: (Intros?) (***)

32. EggMania
Status: (Intros?) (***)

33. Finding Nemo
Status: (Nothing)

34. Fusion Frenzy (Demo)
Status: (Menus)

35. Gun Valkyrie
Status: (Menus) (*)

36. Gun Griffon Allied Strike
Status: (Menus)

37. Halo (Demo)
Status: (Menus)

38. House of the Dead 3
Status: (Nothing) (**)

39. Innocent Tears
Status: (Ingame) (*)

40. Kameo (Beta)
Status: (Intros?) (***)

41. Lamborghini (Demo)
Status: (Nothing)

42. Mademan (E3 Demo)
Status: (Nothing)

43. Oddworld: Munch's Oddyssee (Demo)
Status: (Menus)

44. Myst III
Status: (Intros)

45. Nakashima Tetsunari no Othello Seminar
Status: (Intros)

46. Namco Museum
Status: (Ingame)

47. Otogi
Status: (Menus)

48. Outrun 2
Status: (Intros)

49. Petit Copter
Status: (Menus)

50. Pinball Hall of Fame
Status: (Intros)

51. Quantum Redshift (Demo)
Status: (Menus)

52. Rayman Arena
Status: (Ingame)

53. Shenmue II (Demo)
Status: (Nothing) (***)

54. Toe Jam and Earl III (Demo)
Status: (Nothing)

55. Unreal Championship
Status: (Ingame) (*)

56. Unreal Championship 2
Status: (Intros)

57. Whacked
Status: (Nothing)

58. Zapper
Status: (Ingame)

(*) Distorted gfx
(**) Hangs or crashes
(***) No idea what it's doing (flashy or distorted colours, etc).

Now, I won't stop anyone from making requests, but on a serious note, I can't cater to everyone's personal preferences at once.  This list will be updated periodically, so check back every so often.

Shogun.

Tuesday, April 29, 2014

XQEMU: Smashing Drive Ingame




Okay, we're moving along here faster than I anticipated.  Just a few moments ago, I added a few texture related fixes to XQEMU, and now Smashing Drive goes ingame!  Although there isn't too much visually impressive in this game, it's proof that LLE is a feasible idea.

In my experience, Smashing Drive has always been the easiest Xbox game to emulate (the game is only 90mb, making it the smallest known commercial Xbox game that I know of!), so I'm not really too surprised it's working this well.  You're probably wondering why the colours are inverted, lack of colour keying and depth testing, etc.  The emu actually doesn't appear to implement any render states at all at the moment, and we're still working out how certain texture formats should be interpreted in OpenGL.  Other than that, everything runs with minimal issues, minus the random freeze likely caused by race conditions.

So, just wanted to give you all a quick update on XQEMU's progress as of late.  Thanks for reading!

Shogun.

Sunday, April 27, 2014

XQEMU: Sonic Heroes (E3 Demo) *Almost* Goes Ingame!





Quick update everyone.  Just wanted to share with you all a bit of progress that's happening with XQEMU.  So after spending some time chatting with espes and JayFoxRox, I took a little time this weekend to dive into the code a bit.  So, I fooled around a little, and eventually Sonic Heroes started booting up, and went straight to the menus.  There's no screenshot of the menu here because the screen flickers too much, so I couldn't get any screens of that.  Since the emu isn't stable enough, there are sometimes race conditions that cause it to randomly freeze, so it's not guaranteed to get that far on your first run.

The primary reason I'm so impressed with this is that I never could get this to work at all in Cxbx to save my life, and yet this new emulator comes along (which barely runs any content so far) and puts me to shame!  It's a bit humiliating, but I'm glad to be humiliated for the sake of progress!

And now I have to run out the door.  Later guys!

Shogun.

Saturday, April 10, 2010

Random update






Yup, that's right. I feel like working on Halo right now. Don't like it? Then GTFO! lol, just joking. But on a serious note, I'm sure I'm going to get multiple "wtf"s for multiple reasons. I'll answer your wtf's later. Just trying to piece together an update since I haven't been doing it very often!

It's been a while since I've done any major updates to Cxbx (and I still haven't), but today I wanted to take some time off more serious things and work with Cxbx for a while. Right now, I'm mainly dealing with issues related to games using XDK 3911 (Azurik and Halo in particular) because this XDK internally operates very differently then all other XDKs released after it. Remember playing Halo on Xeon? Ever noticed how bilinear filtering was never present, alpha blending in the wrong places and the walls weren't visible? That's because the Deferred Render/Texture States are in a completely different order than the other XDKs! I found this out when I first tested the code examples for 3911 and noticed that certain render/texture states wouldn't work, and that the wrong ones were being set. I fixed most of this in Cxbx already, and if Xeon was open source, I could fix it there too. Why didn't _SF_ figure this out? Because he never had XDK 3911 to begin with. He was using XDK 4627 to find similarities, and did a good job of it. Still, anyone could have missed this.

"Hold on a sec, why does Halo look orange?" Good question. I don't know. Besides, I thought Halo's old orange UI looked cooler than the blue one (E3 2000, anyone?). Well, don't be surprised. With every new release of Halo (or new major build), there's always something with Halo that causes the menus to look more and more distorted. At one point, you could actually make sense of what was going on. Now you can't, really.

"Why are you working on Halo anyway? There's already a PC port, why not play that instead?" Okay, this gets really old after a few years. First of all, Cxbx is not intended to replace an Xbox or be a substitute for any PC version of any game available. I don't work on Cxbx so all the warez monkeys can play their favourite pirated games either. My motives for working on Cxbx is to further advance the current state of Xbox emulation as a whole and learn a trick or two about how Xbox works and about Direct3D in general. So please, don't tell me what I can and can't emulate. Yeah, it nice to be able to play your favourite games on an emulator when you can't use your console, but remember this... each time another game becomes playable, it increases your chances of being able to play your favourite game in the next release! Besides, I like the idea of playing Halo's Co-op campaign on my laptop with a friend. Isn't that something to look forward to?

"What about the ring? Does that actually render?" Actually, it does. You'll have to put Cxbx in wireframe mode to see it though. I think it's covered up by stuff again.

Defiance and I have been putting our heads together a bit today. Not sure if he'll have time to work on Cxbx for a while, but he's still around. For any of you who actually got Cxbx to successfully get Halo into the menus and tried to start a new game, you might have been greeted with a nasty grey/white screen that sits there forever. Well, I actually got passed that today. From the looks of things, it appears that it might have actually been going towards the ingame status. Too bad I had gotten a fatal error message ruining the whole thing! My debugging information was off, so maybe I can fix it. The biggest problem with Halo is that there are tons of bugs related to this game. Might be Vista related, but it's too early to tell. So getting to that point is all a matter of chance. Sometimes a crash happens, sometimes not. Totally unpredictable.

There, an update. I never thought I'd make so many users sad by taking some time off :) Maybe I should just take time off every other week instead so no one starts complaining :)

Shogun.

Tuesday, March 30, 2010

New Panzer video



I forgot to put this on youtube but, but oh well. What's so great about it? This video actually shows solid 3D ingame gfx of Panzer. The fullscreen quad still covers up the 3D scene from time to time, but at least you can see what's going on for a while. What's the difference between this build and other build featured in the old video? This video was taken in Release mode [from visual studio] rather than Debug. It turns out that Release builds are more stable and less buggy when running Panzer Dragoon ORTA and Robotech: Battlecry. Both games had similar problems. Speed is still an issue, and me and Defiance have tracked it down to the PushBuffer emulation (IDirect3DPushBuffer8, Xbox only). The problem is that it uses a combination of Indexed Geometry and Quad Lists (D3DPT_QUADLIST, Xbox only) and that appears not to have been perfected in push buffers.

Robotech: Battlecry, however, did not use push buffers but did use the same types of primitives using indexed geometry. Defiance fixed that (for the most part). Okay, getting slightly off-topic, but the two games are related though. I'll try to make a video of that soon. Fraps can't record it properly, so I'm using another tool to do so.

So while it's not really news, it's a slight improvement that I want you all to be aware of.

Shogun.

Saturday, January 30, 2010

More on Petit Copter (Ingame)

Okay, last night I was curious as to why Petit Copter kept crashing the way it does. I initially thought it was DirectSound related, but it turns out that it was really a problem with our implementation of EmuIDirect3DDevice8_SetRenderTarget. The fix was so easy, I wanted to slap myself! After that it went ingame.

After going ingame, it turns out that the game is more complex than I thought in some ways. It turns out that the game does actually use vertex shaders! Although that's not really a problem as Petit Copter's vertex shaders were really simple to convert. When I first got Petit Copter ingame, I noticed that the only thing I could see was the helicopter's rotor. This was because Cxbx compensates for the Xbox's ability to use negative numbers to identify vertex shader constants (c-96 to c96), so Cxbx adds 96 to the vertex shader constant ID of each shader instruction to fix that. This caused bugs in games using XDK 4361 and earlier (so far) and caused 3D not to render. So what I did was add 96 in EmuIDirect3DDevice8_SetVertexShaderConstant and everything that used vertex shaders in XDK 3911 - 4361 worked fine. It's a dirty hack and I'm not sure if it's a good idea to leave it there, but oh well, time will tell.

"So, how well does it run in game?" Well, everything is smooth ingame. No framerate issues as the graphics are really simple. "If everything is smooth, why can't it be considered playable yet?" Good question. There's another bug somewhere, and I can't figure out what it is. So far, it's exclusive to this game. There's a stack corruption problem in this game (might be the generated exe or CxbxKrnl.dll causing it) and it's really hard to track! If I can fix that, then the game will be considered playable. The bug is completely random. Sometimes you'll get a crash immediately, other times it won't show up for about 30 seconds if you're lucky. So if you want, watch the youtube video (link below).

Cxbx WIP: Petit Copter [Part 2] (Ingame)

Hope you enjoy it.

Shogun.

Sunday, January 24, 2010

XDK 3911: Random stuff...

Me and our newest programmer (Defiance) have been investigating problems with games and other apps using XDK 3911. It looks like the problems we face with games using this XDK are much bigger than we originally thought. Below is a list of problems I've been able to dig up and how I have addressed or how I plan to address them.

1. The biggest thing so far is the lack of accurate deferred render state emulation. Ever had that EmuD3DDeferredRenderState not found error? Yeah, it has to do with that (sort of). Now that I have 3911 XDK samples to test with, troubleshooting issues with this particular XDK will be much easier. I was testing the basic tutorial examples as they are easy to debug with Cxbx, and noticed that the texture in the Texture tutorial was black! I had assumed that there was a problem with texture loading (there is, but not with this sample), but it turns out that the deferred render states were not being set properly. The example explicitly disables lighting (Direct3D enables it by default), but it wasn't doing it. I disabled lighting manually and it worked. For XDK 3911, instead of directly changing the deferred render states table directly, it calls a function to handle it (D3DDevice_SetRenderState_Deferred), and this function only exists in XDK 3911 and earlier so far. Because of this, Cxbx gets the location of D3D__RenderState (EmuD3DDeferredRenderState) then reads and updates deferred render states until the next draw call. To find it, what Cxbx does is calculate the location of the deferred render state pointer by locating IDirect3DDevice8_SetRenderState_CullMode and then calculating the offset from that function to the list of deferred render states. It appears to work fine for every XDK we support so far except 3911. Since I don't yet understand how Cxbx calculates the offsets, I'll have to use a more hacky method of correctly emulating the deferred render states. This means HLEing IDirect3DDevice8_SetRenderState_Deferred itself. Even though that the render states are supposed to be deferred, I'll set them on the fly and write code to defer them later. It's possible I might have to do the same for the deferred texture states as well (I hope not), but this will diagnose MANY problems you are having with any games released around November 2001 (yes, that means DOA3 and Oddworld). When the deferred render state location code is correct, I'll remove this function as emulating it will no longer be necessary.

2. There is yet another problem plaguing 3911 games. There appears to be a problem related to loading textures with a specific D3DX texture loading function. This is stopping many 3911 games from working (Star Wars: Obi-Wan, Fusion Frenzy, and many more). I haven't had a chance to debug this extensively, but the problem is known and will be addressed hopefully soon.

3. As much as I hate to say this, there's a chance you might be experiencing more "X-Ref only" errors with 3911 titles. Why? Because for DSound, I've added a new X-Ref that will help me quickly identify and fix missing DSound APIs, DirectSoundEnterCriticalSection. AFAIK, this is called in every Xbox DirectSound API. There are some missing DirectSound functions that can be executed by Cxbx and not crash leading to further problems. So when a DirectSound function call is missed, I can easily find out what it is thanks to the breakpoint that I placed before the message is displayed. Yes it will get annoying as heck, but it's for your benefit!

4. One more thing, I finally got around to adding the XGRAPHC library support for 3911. I'm surprised no one did it before o_O. I added every XG function that Cxbx emulates (except for one), so that will fix alot of problems right there.

I wanted to say more, but I can't remember what else I was going to say, lol. So I just wanted to let you all know what I've been up to lately. So stick around, and see what I have in store for you all.... hahahahahahahaha!

Shogun.

Saturday, January 2, 2010

Dead to Rights






I know it's late, but Happy new year! Anyway, I'll cut straight to the chase today and I'm going to make this quick. I got the game Dead to Rights to go in-game today (with an asterisk), but chances are you probably won't be playing it by the next release. Why not? The bug fix for this game (which technically isn't a fix) will break every other game. In order to get in-game, I had to disable calls to IDirect3DDevice8_DrawIndexedPrimitive. There's yet another undiscovered bug inside of EmuIDirect3DDevice8_DrawIndexedVertices. So far, I don't know what it is or how to fix it yet. Once again, a fullscreen quad is overlapping the 3D scene just like in Panzer Dragoon Orta. I also had to disable overlay updates to prevent crashing like in Unreal Championship (that's one reason why you see a white screen in the background).

This game may not be as visually impressive as many others, but this game uses alot of functionality that Cxbx did not originally support so even though it only took me less than 2 days to get this far, the difficulty of emulating this game is still not to be underestimated! Even though I'm not yet successful in getting this game playble yet, it was a good experience for me and showed a few areas where Cxbx was lacking. See? Emulating an Xbox game with a PC port CAN be beneficial! Until next time.

Shogun.

Friday, December 4, 2009

More on Unreal Championship

If you've read my last update on Unreal Championship, you'll have a good understanding by now what the situation is. If not, you might want to read that first :)

So, now what's going on? So far, this is the most interesting situation I've come across when working on this emulator. The solution to it might be even more interesting (or annoying). I'm not really sure which would be the best way to go from here, but I do have two ideas for this scenario (to handle the problem with the xbe trying to re-launch itself). When XLaunchNewImage is called (and when the .xbe being called is itself) and the LaunchData parameter is saved, we can either:

1. Trigger some sort of "restart" process inside the CxbxKrnl so everything except the necessary things are in the initial state at which the game was started. Then jump right back to the game's main entry point and continue as normal. Optionally "Persist" the display until D3DDevice::Present is called.

2. Save the contents of pLaunchData to a file in the same directory of the game (it's size will always be 3KB). Then load the file and restore certain states the next time Cxbx is running the same game. This will require you to restart Cxbx each time you want to go in-game.

Remember, I said I'm looking for the "best" way to handle this, not the most "ideal". I know everyone would rather have me do number 1, but so far I've only had time to try number 2. This is what happened...


Rats! To a certain extent, #2 does work, but it does have one small problem. The controller needs to be re-initialized so that the game will recognize that it's still there. This will require a bit of hacking. So far, it appears that everything else worked fine. All the files required to load the map, etc. were loaded without problems. But so far, it looks like #1 is harder to implement and #2 requires more extensive hacking. Maybe a simple jump could fix everything (for #1)! Since I'll be busy tonight and all day tomorrow, there's no telling when I can actually try it. Hopefully Caustik can jump back in sometime and give a few suggestions, but unfortunately, it appears that I'm the only one on the Cxbx team that has this game.

I'd really like to get more in-depth on this, but atm I have much work to do IRL so just stay tuned and I'll see what I can do. There's a lot that can be done with this game (once it works), but you'll just have to see if/when that happens :)

Shogun.

Thursday, December 3, 2009

Unreal Championship progress...








Yeah, it's been a while since I've worked extensively on this game, but yesterday I had lots of time on my hands so I went at it. Before I go any further, I'd like to thank Chrono Archangel find a certain XNet function (XNetGetEthernetLinkStatus). Without his l337 google skills, I might not be posting this right now!

Unreal Championship goes comfortably to the menus (and is more interactive) with little or no problems. So far this is only for the NTSC version. It required a small handful of hacks, but so far it looking good. Since the game uses time based updates, you don't have to worry about it going to fast when VSync isn't enabled :) I also learned a few new tricks when emulating this game! Even though UT2003 for PC is practically the identical in many ways, IMO this game is too different so I say it's safe to consider this game an Xbox exclusive (that's one reason why I own both).

If you look at the screens, you'll notice that it looks as if termites have been eating some of the textures. "What is it?" Not 100% sure, but my guess is either it's another swizzling issue, or it's a palettised 8-bit texture and the conversion from D3DFMT_P8 -> D3DFMT_A8R8G8B8 isn't perfected yet. One thing I noticed was that so far, XACT wasn't really used much after loading one wave bank (which was surprising), so I might not have to implement the whole XACT API after all (which would be a major sigh of relief).

Now for the list of hacks needed. The first one I should have mentioned before. Sorry to those who tried running this game on my branch before with no success.
  1. At one point, I was trying to add a missing DirectSound API and I couldn't generate a digital signature for it. So what I did was I made a copy of my xbe and filled that function call with NOPs using a hex editor.
  2. Disabled overlay updates so that the second video can play. The first video works without the hack, but when the second one plays without the hack, it will cause a crash inside of the DirectDraw DLL. I couldn't think of a better solution at the time so I did this.
  3. For some reason, Unreal likes to lock it's textures at each level until it fails. So I had to tell EmuIDirect3DTexture8_LockRect to fail when the texture level is higher than 5.
  4. This last hack probably won't work for everyone, but I added a hack in EmuIDirect3DDevice8_SetIndicies to stop it from crashing because the IndexBuffer pointer appears to be bogus. If you get a CreateIndexBuffer failed error when trying to go passed the first menu screen, try it again.
These were some dirty and totally ugly hacks used (and I had a feeling that this was going to happen anyway). Oh well, as long as it works, right?

"So, what's stopping it from getting us in game?" Okay, here's where it get's complicated. It's bad enough that Unreal Championship uses features that are rarely used in Xbox games (or should I say features that we're not used to emulating for Cxbx?) which makes things a bit more complicated, but it's biggest feature is getting to us. Unreal Championship was the first console game in history that supported [executable] patches for the game. This means that in order to run that patch, it has to execute a new .xbe file. Cxbx is currently not capable of doing that. But what if it's not there? What it appears to be doing is loading the default.xbe over again if it isn't. It may have been designed like this as a cheap way of clearing most data from memory. So, that's the problem... but what about a solution? Here's an idea. I added the function XLaunchNewImage today to see what it was trying to do. Just as I stated above, it's just re-executing itself. Wouldn't that just start everything over? No, not really. Fortunately, the XDKs documentation on XLaunchNewImage is quite adequate, well written and very informative. Since an Xbox .xbe's entry point (void __cdecl main()) does not take any parameters (i.e. no command line), they have to be set using XLaunchNewImage. The function XGetLaunchInfo is used to retrieve the the data set by XLaunchNewImage. Since Unreal appears to be going back to the entry point after attempting to reload default.xbe, there's a chance that we can fool it by saving the params from the last call from XLaunchNewImage so that they can be retrieved by XGetLaunchInfo. This might work, and it might not. It's worth a try, and so far, I don't see any other options as of now. I'll give it a try, but just know this. I can't guarantee that I can get this one in-game. I can only guarantee my best efforts!

One more thing, I'm looking for anything on the .xbx file format. What is an .xbx file? It's a customized texture format for the Xbox. Since Unreal Championship calls XGWriteSurfaceOrTextureToXPR to create it's icons, it would be ideal to be able to create this functionality just in case the icon is actually used. So if you can find any tools, have any source code that deals with this file format, let me know!

Before I conclude this update, I just want to thank all the Cxbx supporters and fans that have been keeping up with us for all this time. Chrono Archangel, Mr. Fabulous, saintseiya, nokiaman, and more, I really appreciate you all!

Shogun.

Sunday, November 29, 2009

Martin_sw continues his work for Chihiro support.

It's been a while since I've talked to Martin_sw, but today we were having a conversation and so far, it looks like he hasn't given up. Here's what he had to say:

"ok, seems sega just highjacked it for chihiro then so far i have added these to cxbx:

JvsScFirmwareDownload@16
JvsScFirmwareUpload@16
JvsScSendRs323c@12
JvsScReceiveRs323c@12
JvsScSendMidi@12
JvsScReceiveMidi@12
JvsEEPROM_Read@16
JvsEEPROM_Write@16
JvsBACKUP_Read@16
JvsBACKUP_Write@16
JvsNodeReceivePacket@12
JvsNodeSendPacket@12
JvsFirmwareUpload@16
JvsFirmwareDownload@16
JvsRTC_Read@16"

This is interesting because even though it's obvious that Chihiro would have customized functions, but it's amazing how fast Martin discovered these. It looks like we might be seeing Chihiro sooner than we thought!

Another thing, remember that game I was going to surprise you all with? You all guessed right, it was JSRF. I hate to say it, but it might not be playable before Christmas at this rate (darn)! I ran into some extremely annoying problem and I have no idea how to fix it (for both PAL and NTSC versions). *Sigh*, oh well, I'm sure I'll figure something out, but as long as you know I'm working on it so you don't have to beg me for JSRF support anymore. Either way, I can still make up for this with something else in the meantime *muwahahahahahaha!*

Shogun.

Monday, November 16, 2009

Cxbx and OpenGL: Time to shed some light on this topic...

Okay, this question has come up many times (even more ever since I started that poll on ngemu.com getting opinions on an OpenGL port of Cxbx). Will Cxbx be ported to OpenGL? That's part of my plan, yes. For those of you wondering why I'd do such a thing, I'll give you an explanation as to why.

Ever since Cxbx has been released, you'll notice that it has been using Direct3D 8.0; notice a problem already? Direct3D 8 has been depreciated a long time ago and it doesn't really have any good debugging tools anymore. IMO, the driver support for Direct3D 8 isn't that great either. To top it off, PC standard Direct3D8 (and 9) does not contain all of the functionality we need to emulate the Xbox. Fortunately, OpenGL does! Using OpenGL will allow us to have a much cleaner implementation for certain functions if implemented properly. Some say that because OpenGL isn't COM oriented, an OpenGL port would be too hard. No, not really.

Ever heard of Wine? We can always use the WineD3D implementation instead. This way, we can basically have our own customized Direct3D library, and add all the custom functionality that standard Direct3D lacks... and still be using OpenGL the whole time! I've already picked up the idea and have been planning my implementation of WineD3D into Cxbx. It would be easiest to just take the needed code from WineD3D and create a custom library and call it WineX or something like that. Thank God it's GPL :)

So there you have it. An OpenGL port is planned, but as of now, it's still not a top priority. But once implemented, we can easily test it against XDK samples to ensure accuracy and speed when necessary.

Shogun.

Monday, November 9, 2009

Robotech: Battlecry... hey, it was working a minute ago!!!

*sigh* I hate it when this happens...

Even though I'm still taking a break from the scene, I just thought I'd share this with you all anyway. Today I was getting curious about Robotech Battlecry again (XDK 4721). In general, I just wanted to see if anything I added in for Panzer fixed this one. It appeared that way, but then again maybe not. I booted up Robotech Battlecry with Cxbx, and it appeared to go in-game without problems (by problems I mean crashes). The distortion of 3D was worse than that of Panzer TBH, but at least it worked! I did take some screens though (how could I not?) so check 'em out below.






In-game, as I stated earlier, the 3D scene was heavily distorted! I should have taken a screenshot of it, but instead, I closed Cxbx in an attempt to run it with a Release build because I had the debug trace enabled and the debug console was also on and I wanted to see how fast it would run without the console slowing it down. After that, it never worked again! Debug or Release build, it just crashed. It appears that the DirectSound call that was causing the crash didn't get called that time. I'll look into the problem later as I am just way too tired right now.

When will I be back, you ask? I dunno when, but right now, the IRL issues are enough to keep me busy and sleepy throughout the day. It shouldn't be too long since I tend to have lots of free time these days. But today is not one of these days, so stick around. I have lots more tricks up my sleeve!

Just thought I'd keep you all posted on my progress today (even if it was just a one time fluke). So if you'll excuse me, I'll be taking a nap now!

Shogun.

Friday, November 6, 2009

Taking a break for a while.

Ever since I started working on Panzer, it's been taking a lot of my energy. Right now, I'm completely burned out from working on Cxbx. We all get this way. Don't worry, I'll be back. Just remember, we all have lives outside of the scene. I feel good that I've gotten this far, but sometimes you just have to take a step back and get back to other things for a while because the excitement is just killing me (literally, in one way or another).

Also, it may not be to long until Caustik is back in action. I won't say much at this point, but I think it's going to happen rather soon.

Before I go, I just wanted to share something with you all (just in case you haven't seen it). I made a youtube video of Panzer Dragoon ORTA ingame if you're interested in seeing it right now. So far, only the NTSC version is compatible, PAL doesn't work yet.

http://www.youtube.com/watch?v=4i6fmVuFgvA


When I come back, I'll try to fix a few more issues with Panzer and get back to work on a few other games I started working on, like Robotech: Battlecry and Unreal Championship, okay?

Shogun.