Videopac / Odyssey2 forum
February 22, 2020, 10:04:02 AM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News: If you have some news and you want it to be shown here, pm Janzl!
   Home   arcade Help Login Register links  
Pages: 1 2 [3]   Go Down
Author Topic: Take the Emulator and Run! - New emulator -  (Read 15956 times)
Played Munchkin once...
Posts: 94

« Reply #30 on: November 01, 2007, 03:31:10 AM »

Hi Fernando. Have you some idea how many time is needed to we?ll hear the Voice working perfectly. For reference you can check the PDF website:
I think that better voice support is possible (it all boils down to the quality of the samples). I haven't taken a look at the voice emulation code in O2EM, but I believe we can use more aggressive preloading to make the gaps between samples be reduced or even disappear. To be honest, I never coded anything related to sound (except for a WAV player and spectrum analyzer in QBasic a long time ago, which is a completely different "beast"), so the best answer to your question is probably "not so soon" (in fact, voice support isn't even planned for 1.0).

- The quad cut doesn't seem to work properly yet.
Yeah, there are still some problems with quad handling. That binary was r10, ttear is in r12, and I remember working on improving quad char support, so that might be solved already. When I first implemented quad cutting, I was using O2EM 1.16 which apparently doesn't handle quad cutting correctly. Later on I reworked that based on a comment by S?ren Gust in the source code for O2EM 1.18.

- when I move a sprite with the joystick, it always takes steps of 6 pixels.
That could have something to do with event handling (in r10 we used to capture an event every 6 VDC cycles, I think). That part has also been changed in recent commits, so I don't know if this is still an issue.

- I don't seem to be able to use the '?' or '+' keys (to get the corresponding symbols on the screen).
- could you make it more "laptop-friendly" by using the normal ENTER key instead of the "enter" key from the numerical keypad?
I noticed weird behavior as well, it's high priority in my TODO list. The keyboard code seems to be completely busted, some times using O2EM-style caps-lock for alternating between controller and keyboard works, and some times it does not (I think that's related to focus issues in SDL, but I have to investigate further), some keys are not working at all (I suspect it's related to the key alias code), etc.

By the way, the return key is an alias to the enter key, which maps to the enter key of the Odyssey. So it's already there, it's just broken. Tongue

It's been almost a month since the last time I had time to spend on ttear. r13 will bring big changes to the way the VDC class works (following Rene's description of how the VDC works), and I might also need to rework events once again and things like that. r13 might be out in two weeks (life's really busy at the moment  Undecided).

The VDC and the VM are the most tedious and time-consuming parts of the emulator, and for the next few revisions they're expected to be broken. Future revisions will fix the issues caused by all those major changes, when the core is finally stabilized.

I appreciate your feedbacks.
I take the Videopac and leave the Canoli!
Posts: 2515

« Reply #31 on: February 07, 2008, 12:48:15 AM »


I?ve reading on Orkut there?s a lot of people wich like to use O2em but they having some kind of problem. I haven?t problems with it, but maybe you can make tter an easiest emu for the people who wants to remember the Ody without headache. I really don?t know the problems they have, but there?s a Colecovision emulator called Koleco_vos and it don?t need configurations.
Played Munchkin once...
Posts: 94

« Reply #32 on: March 07, 2008, 09:44:38 PM »

TTEAR will be as user friendly as O2EM, except for a cleaner layout for the command line arguments (no "-nosomething madness"). What users probably need is a more user friendly frontend, not a more user friendly emulator.

I plan on working on a frontend for TTEAR once it reaches 1.0. It's going to be well integrated with TTEAR and it will use a ROM database as well, probably based on the TVB database, but with more open standards (no, ODBC is definitely not cross-platform) and it will require no extra dependencies (such as .net). A wizard will help you to set the environment up, as this seems to be what most people consider the tough part.

But this is not high on my TODO list. I'll give it some thought when I can play Frogger at 200FPS on a Pentium 2, with sound enabled.
Marcelo Ribeiro
Trying to get the cartridge in...
Posts: 6

« Reply #33 on: April 17, 2008, 10:58:54 AM »

It's really exciting to hear that an Odyssey2 emulator is being developed.

Mainly because the O2-emulation world is a big "mess"!!! The O2EM has been left unfinished, the O2EM Launcher didn't come together with the O2EM releases, TVB is in my opinion too heavy and complex, and M.E.S.S. is trying to reach the current state of O2EM...

I hope we can use an almost fully playable 1.0 version of TTEAR soon, even if it doesn't support voice & VP+ emulation. Good job, Fernando!

By the way, I'm new on this forum, so I didn't have the chance to vote for the emulator name... TTEAR is really strange to me... I would prefer something like "Averett", in homage to Ed Averett, the most important O2-games creator.

I'm happy to be in contact with you all again!

Give this man a Jopac!
Posts: 1060

« Reply #34 on: April 18, 2008, 01:01:08 PM »

Take the Emulator and Run
I like this one!  Smiley
So far it's my favourite as well (in fact, Take the Emulator and Run!, with the bang). I really liked Air-Sea-War Emulator and Pixel Axe Pete as well.

I'll create the project page on friday if all goes well, and if there aren't any better suggestions, I think i'm going with TTEAR!.

Thanks guys, keep the ideas coming.

I am just wondering from the screenshot, what operating system do you use?
Played Munchkin once...
Posts: 94

« Reply #35 on: October 13, 2008, 07:10:09 AM »


It's been long...


Thanks! I don't think TTEAR 1.0 will be out soon, though. I really don't have enough spare time to dedicate to open source projects at the moment, but I'll try to keep a slow but steady development pace.

Regarding the naming decision, I'm used to call it TTEAR already, although yea, it does sound weird when pronounced. I really liked your suggestion. At this moment, I'm trying to focus on the core stuff only (the code). Many open source projects have never reached an usable state because the devs focused too much on things like naming and appearance or got stuck in early design decisions, and in the end, there was too much talk and not enough code.

We can change the name later on if we decide it's not good enough (although the "unix" name on BerliOS must remain "ttear", I think). We also need a decent installer, a GUI frontend, etc. But first things first. Wink


Heh, I think I already replaced the screenshot you're talking about, so I have no idea (I have used many different OSes and window managers in the last couple of years/months).

Now an status update. I haven't had much time to play with the code (I hadn't touched the code in a couple of months until today, to be honest), but since the latest "release", many things changed under the hood.

I don't remember exactly what the previous binary release contained, so this status update might be somewhat innacurate. As of revision 29:

- I split the framebuffer code in vdc.cpp into an abstraction with two implementations: an implementation which uses the SDL 2D primitives and one which uses OpenGL accelerated blits and resizing.

That means that if your video card supports hardware 3D acceleration, the OpenGL mode is really fast and scaling is very smooth. Also, since we're using OpenGL, it's easier to implement filters to simulate the "old CRT feel" or any other effect.

- We now render a much larger screen (5x the Odyssey's visible screen size), then scale it down. That's because, as Rene's pointed out, the sprites' leftmost pixel is about 1/5th of the regular pixel size and characters seem to be offset by this same amount as well. This setting is configurable, so, for example, we can disable it for embedded devices with more limited processors/GPUs. I need some feedback on how accurate this is.

- Collisions between the screen objects are disabled at the moment. They'll be implemented as soon as I find a way to do it without ruining performance (bounding boxes, caching) or code quality.

- Sound is also not implemented yet.

- A huge part of the VDC code has been rewritten. The code has been split up in smaller entities. Performance has been largely improved. The characters are now pre-rendered to video memory, so blitting them is really fast (especially in OpenGL mode). The same caching technique is being applied to other objects as well.

Instead of drawing a small part of the screen on every VDC step (and there are a lot of VDC steps per frame), we now draw the screen only once and then update it as necessary. Only the affected area is redrawn. This translates into huge performance gains. For most games, the screen is only drawn once.

There are tons of bugs remaining:

- Keyboard handling is still a bit weird. I haven't had the chance to investigate this yet.

- We have lots of tiny timing errors. Therefore, some games are running slow (Pick Axe Pete!, for example) and some games which previously displayed just fine now show a lot of flicker (Chez Maxime, Power Lords). Those aren't regressions though - we always had those bugs in the code, but now they're exposed by a better design that allows things like vertical midscreen changes.

I think I got some parts of the VM/VDC logic wrong. If we could create a minimal sample which detects the timing errors, maybe we could finally get rid of those annoying timing issues. The whole timing code is very fragile (a single off-by-one error causes a huge difference), perhaps we need more people reviewing it.

- I feel that some games won't work because I don't have sound implemented yet, this could interfere with timing.

- OpenGL isn't working for me in Vista, but it works fine in Linux. YMMV, and I'm honestly not worried about it now. I'm currently cross-compiling TTEAR with MinGW, it's ugly and error prone. The switch to CMake will make TTEAR much easier to compile with VS Express, and that's what we're gonna use for real releases. This might automagically solve some Win32-specific bugs, so this is not top-priority atm either.

Here's a link to a zip file containing the O2 BIOS ROM, VP39 (my favourite game, and it also shows the performance improvements), ttear.exe, SDL.dll, ttear.ini and a batch file called run.bat:

I'm posting it at RapidShare because this is not an official release, and also because posting ROM files at BerliOS could get me banned from there. Wink

The ROMs are included for your convenience only. Customize ttear.ini as you wish (OpenGL is disabled by default because it isn't working for me on Windows) and run run.bat. If you want to play other roms, edit run.bat or launch ttear.exe from the command prompt.

Any feedback is appreciated, but keep your expectations low.
I take the Videopac and leave the Canoli!
Posts: 2519

« Reply #36 on: October 27, 2008, 10:13:48 PM »

Probably due to the scaling the width of a pixel now depends on the X-position on the screen.
Pages: 1 2 [3]   Go Up
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!