Just a note I released Reality Boy 0.84 today. DogP added in some verry nice enhancements (sound, etc) so I bundled it up and let it go. Many thanks to DogP for his hard work. You can find it on my homepage like always.

David

Sweet! Glad to see you got to posting it!

On a side note… I haven’t been able to compile this last merge of the code… I get lots of errors, so I’ll have to dig into it some more. I’m still using Visual C++ 6 though. The last versions where you had used .Net hadn’t been a problem, but for some reason, something in this version gives me warnings such as inconsistent dll linkage, and then an error of unresolved external symbol set_window_title. There were a few other changes you made that were incompatible (like long long int, which VC6 doesn’t recognize), but those are simple changes. I really haven’t spent more than about 30 mins trying to get this compiled, so it may be something simple that I forgot to change.

BTW, as far as sound emulation goes… it’s not perfect, but it’s pretty good in most cases, with no support for modulation, and I believe sweep is incorrect, and I think some of the noise channels don’t work (I think it’s a problem with something I set up in Allegro). Link port emulation is not really playable over the internet (too laggy), but it works well for development on the same computer connecting to localhost (or for turn-based over the internet). My link code for 3D Battlesnake and TicTacToe on my site is flawed… I’ve made the changes on my local computer, but I haven’t uploaded it yet… once I upload it, you guys can use that code as an example to experiment w/ the link port.

I think the rest of the changes are listed in the history.txt file… of them, notable are the fixes of some affine stuff (which fixes the graphical problems RB had w/ MK’s VB Racing, along w/ various minor problems seen in other games). Also, I added cache profiling in the debug version (reality_boyD.exe), which you can press ‘\’ to display cache stats, and ‘/’ to clear them.

The interesting thing with that is seeing how almost every VB game just turns on the cache and leaves it… which is horribly inefficient. Teleroboxer is the only game that I noticed to actually enable/disable it, but during the game it’s disabled almost the entire time (once again, inefficient). To supplement my post in the dev section about cache usage… if you check my Mario Kart game w/ this, you’ll see a very high cache hit ratio, along with a high percentage of instructions cached… this is good use of the cache. That’s the real reason I added this… so when you’re developing a game, you can optimize your cache usage.

Oh, and I fixed the Save RAM bug that KR155E pointed out.

DogP

nice. it runs well. i did have one problem, though. the sound was going waaay slower than the actual gameplay. i messed with some options which would make the sound slower or gameplay faster, but not the other way around. just a heads up.

great news!
how do i use the link port emulation? just starting two instances of the emu? how do i enter the ip info?

Yeah, you’ll need to start two instances of the emu, and use a command line argument for the ip. I don’t remember the exact syntax, but it’s something like “-network host” to host a game, and “-network ” to join a game. You’d use “localhost” or “127.0.0.1” to connect to your own system. If you look at the usage from the command line (by just running reality_boy with no arguments), it’ll tell you the correct syntax. RunnerPack also updated the frontend to allow all the new options to be selected from the frontend, although I don’t think his changes made it into this release (maybe he can post it seperately).

IIRC the current TTT and 3DBS don’t work on it though, because I made a stupid mistake in the code, which surprisingly works on real hardware (could actually cause bus contention). I’ll post the new versions w/ the new source when I get home tonight.

DogP

Great work David and DogP! This made my day 😀

Small issue though, the included frontend crashes immediately when run (on windows vista x64). The actual emu works fine though.

Old frontend works, but wont work with the newer emu of course…

DogP,

I definitely recommend downloading the ‘lite’ edition of visual studio 2005 from Microsoft, It would be a better platform than VC6 and would fix your compile errors.

The set_window_title error is probably caused by a different version of Allegro. I am using 4.22. The newer beta code is way to messed up to be usable. Also I am now linking Allegro staticaly, so no need for the allegro.dll. You need to rebuild allegro with the static option turned on.

If RunnerPack sends me code, I will gladly merge it in. I think all the options are covered except for -network, I was just to lazy to hook it up.

I have a copy of vista 64bit at work, I will test this out and fix the crash. I will probably be merging the front end directly into the win32 release so this acts more like a proper windows application. But that may take a while.

David

ps Many thanks to DogP he did 99% of this work, I can not take any credit.

Yeah, I’ve considered getting the free Visual Studio 2005 (or even the full version that I am licensed for from work)… but personally, I think .Net sucks. For almost all the apps I write, what should be 50k (compiled w/ gcc) is usually about 100k w/ VC6, and 300+k w/ .Net. I just dislike the extra bloat, and I really hate .Net framework, and some of the other crap that many programs compiled w/ .Net require.

I guess it’s just VC6 is what I’ve been using forever, I’m comfortable w/ it, and it doesn’t have those extra annoyances that the newer VS’s have… I’ve never had anything that I wasn’t able to do w/ VC6… although I do very little GUI work, which I’m sure .Net greatly simplified.

That’s good to know about linking Allegro statically… that’s probably the dll problem that I’m seeing. I think I’m using Allegro 4.22 as well, but I’ll check that too.

BTW, I uploaded the fixed link games: http://home.comcast.net/~virtual.boy/projectvb/tech/programming.html … I don’t remember if I ever tested them on hardware though… but I’m pretty sure they work. Tron (3D Battlesnake) doesn’t work correctly in the emu because the freeze of direct framebuffer drawing doesn’t work correctly, so it’s just moving dots rather than leaving lines (makes it pretty tough to have a collision). TicTacToe should work, and should be a good example to write your own link code from.

If we could get the direct screen drawing working properly, I think we’d have 100% emulation (not 100% perfect, but all games would play with reasonable accuracy).

DogP

First, thanks go to David and DogP for all their work to make such a great emulator!

David: I will send you my front-end code soon, but it’s not working with the new emulator and I don’t know why. I have VB ROMs associated with the emu in the registry, and that worked just by changing the executable path…

I’m also almost finished reworking and updating the html docs.

DogP (and others who hate VC7+ ;-)): I got RB to compile in VC6. It was quite difficult, since I also had to compile Allegro, which was in turn complicated by the fact that I had already built it under cygwin… In short, it was a pain! For example, Allegro wouldn’t link until I changed /dll to /DLL in the linker command line. 😕

Anyway… First, you have to convert the VC7 project with this tool. Then, allegro\cp_io.h must be edited as follows:

(Delete “” ones.)

.
.
.
!> #define ALLEGRO_MSVC
#include 
.
.
.
 typedef LONGLONG VB_INT64;           //64 bit int
 typedef ULONGLONG VB_INT64U;         //64 bit Unsigned
    
    //64 bit constants are not cross platform compatible
 #define sign_32(num) (((num) & 0x80000000) ? (VB_INT64)((num)|0xFFFFFFFF00000000I64) : (num))

I’m not sure if the “ALLEGRO_MSVC” line is necessary.

I also had to get “inttypes.h” and “stdint.h” but I can’t remember what was complaining about it…

Also, I don’t know if it’s necessary, but I recently upgraded my Platform SDK to the latest that works with VC6, which adds a lot of XP/2003 stuff. It’s the 300+MB of stuff found here: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm. If you use VC6 and can spare the time/bandwidth to download it, I recommend it.

And now, I must go to bed. 😛

Cool… I’ll have to try that… I already made the changes in the cp_io.h, along with a few other simple things… and yeah, I just recently upgraded the Platform SDK to get the Winsock stuff working for the link port emulation. Rather than converting the VC7 project, I just modified my original VC6 project from the older RB version and rearranged the file structure.

I’ll have to rebuild Allegro and see if that solves the problem… that looks like the most likely culprit.

DogP

what is the Problem with the Framebuffer?
Is this hard to emulate?

Emulating the timing of the registers is a mess… I wanted to fix that problem too, but since I didn’t write the original code, it made absolutely no sense to me. I’m hoping David will have a chance to rewrite that code. Red Alarm is kinda playable as it is… 3D Tetris is worse, but almost playable… Golf is unplayable because it doesn’t freeze the screen like it should. That’s the same problem that causes 3D Battlesnake not to work (and probably Etch A Sketch, and other homebrew direct screen drawing apps that disable the framebuffer refresh).

DogP

I figured out why the front-end doesn’t work: the sound “volume” switch is missing.

Also, IMHO, invalid switches should not prevent the emulator from running. RB should just print an error message to the log/stdout and keep going.

And I figured out a way to make the official front-end work on vista 64-bit:

Right click->properties->Compatibility->Run this program in compatibility mode for: “Windows NT 4”.

(Windows 95/98/Me mode also works, but has severe redrawing issues when starting the emulator, which makes vista switch from “Aero” UI to “Basic” UI).

The frontend uses an old manifest file from VC6 to enable the XP look and feel. I suspect that is what is causing issues with XP64. I will fix the missing parameter and stop RB from exiting when passed a bad parameter. I agree it is a little harsh right now.

David

This is some great news! I will check it out tomorrow on my Win machine (I’m on my Linux laptop right now).

[Nitrosoxide]

Its still not in a playable form is it?

I tried Wario Land and while I could move the character it was still very slow. Like it felt like I was jumping on the moon.

Or are my setting not configured properly ? I’m running WIN XP

Either way keep up the good work. Its amazing that this even supports 3D glasses and everything.

Though I do wish there was joystick support.

• This reply was modified 15 years, 10 months ago by Nitrosoxide.

What speed is your PC? Running some games in 3D mode takes a lot of juice… nothing really wrong with the emu except that it’s not optimized very well.

About joystick support, a utility like joytokey works well.

DogP

Here’s my PC Specs

Intel Pentium M 1.73 GHz, 504 MB of RAM

what can I do?

Hmm… upgrade, or start optimizing Reality Boy 😉 . 2D runs fine on my Core2Duo 2GHz w/ 2GB RAM laptop, but 3D Wario Land is still somewhat slow motion. I assume a faster CPU would speed things up, although there’s no multithreaded processing, so it wouldn’t run any faster with more cores, other than the ability to dedicate an entire core’s processing to Reality Boy.

If you just want it to play at full speed and don’t mind some of the annoying effects, you could use the frameskip option (-frmskp (0-9) )… on my laptop a -frmskp 1 runs full speed, but you get the problem of flashing graphics (single frame) disappearing or not flashing, depending which frame is skipped (if you get injured, sometimes you’ll be invisible, other times you’ll be solid like nothing happened). At -frmskp 2, you don’t have the single frame flashing problem, but screens that have animations of 3 frames look to stand still… like the propeller on the main Wario Land screen. It also starts to look kinda choppy after a couple frame skips.

You can see how many FPS it’s running at by pressing 0. I don’t know if there’s a problem with the frame counter or the throttle, but on my laptop it seems to report 46FPS when it’s running full speed, even though it should be running at 50FPS.

DogP

I tried frame skip at 10 and I’m only getting around 10 FPS…

I’m surprised. I can run N64 and gameboy advance emulators perfectly fine.

Is there any way to make it so the emulator doesn’t need a much “juice”.
Can a future update fix this?