Related
I'm quite pissed.
Before Windows Mobile 2005, HTC did not make their camera API public, so developers could not make use of the camera.
This all changed with WM2005 and the introduction of DirectShow. For devices released in the first year (since release of WM2005), this meant that one could "simply" use DirectShow to access the cameras.
But then HTC fell back to old habits again:
The HTC TyTN (Hermes) reports only a single video mode via DirectShow: 160x120 at 7.5 fps, which is a joke. Furthermore, trying to access the front camera via DirectShow fails too: It is simply not exposed (enumerated) at all.
The HTC Mteor (Breeze) goes even one step furher: It does report 160x120 and 320x240 (both at 15 fps), but actually both modes deliver pictures at 160x120. For the 320x240 mode, everything seems to work fine: IMediaSample tells that the picture is in that resolution. The memory buffer has the correct size (320x240x12bits), but the image in the buffer is really just 160x120.
Of course I tried several ROM versions (HTC, i-mate, etc.) but no chance.
So, I'm quite pissed. I already tried calling HTC but didn't get very far (which makes sense if these restrictions are on purpose...)
Daniel
No comments on this?
Nobody every using DirectShow?
I guess I also wouldn't do it if I wasn't force to...
Daniel
So with simple words if you want to use WM5 camera api in your application you can not do it in any HTC device
So how did the makers of CoolCamera go about? I was kinda under the impression that it used wm5s camera api, or am I wrong?
I think they've rewritten the interface from scratch. Look into the CPU developers' manuals. Not a small endevour!
V
CPU Developers' manual
Hi Vijay555,
Would you be so kind to post a link to where I can get this manual ?
Thanks in advance!
I don't think anyone wrote anything from scratch nor do I think this has much to do with a CPU manual... the devs at CoolCamera may have *somehow* managed to get their hands on the infamous HTC TyTN camera api... what exactly are you referring to when you mention the CPU manual?
Also, has anyone ever found a location where this api may be available or a means to get it? HTC developer support is non existant.
Eric, what makes you so sure that they didn't write it from scratch? Maybe they did acquire illegally or otherwise HTC's intellectual property, or maybe they just did what other manfacturers do and wrote some code.
Look at the device support - it's not a single device, it's many, across many different CPUs (Intel, Omap, Samsung), across many different camera sensors and support chips. However, implementation of a camera at software level is not impossible: how else do companies sell their sensors and chipsets?
http://www.ovt.com
Ask the sensor manufacturer, they'll give you chips specs, schematics, implementation code and draft driver code.
Then, look up the SC32442A developers' manual and you'll see that it encompasses a camera interface, again with necessary schematics and hardware IO information.
Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V
they need to continue writing then because my camera application frequently fails in that pictures are corrupt, can't be viewed, and the picture review is just black
Sure it's hard to write a camera interface, but once you've written one, it gets easier to support others.
V
Click to expand...
Click to collapse
What kind of effort are we talking about here? Days? Weeks? Do you think this would need to run in kernel space, or we could get away with user space?
Hi all you great minds out there.
I've been hunting around for a little while trying to find out if this is possible.
I've got this program on my PC called Guitar Pro, a cracking little program which plays midi and guitar tabs together on screen so that you can follow on the guitar, theres a huge online archive of songs that have been converted to guitar pro *.gp3/.gp4/.gp5 format.
Its been great but I find it most annoying that I have to sit in front of my PC to work with this program, so I was really hoping for a program that would recognise the Guitar Pro tab format and run them back a full/half speed ect. I not even that fussed about the midi background.
Now, according to the Guitar Pro website, they MAY release a pocket PC version, this has been the stance for about 2 years, so I can imagine that its a non starter.
Looking around the net I found a program called DGuitar which is supposed to be able to run on any platform with Java, I managed to get a .Jar file to play with but it doesn't install on my pocket PC (would have been a bit too easy eh)
I dont suppose anyone has any input to this conundrum?, perhaps Im being a bit of a lemon with the DGuitar JAR install? or maybe theres another bit of software out there?
Id love to hear everyones input into this, cheers in advance y'all
P.S. I attach the open source DGuitar files to this mail perhaps someone might be able to take a better look at the distribution files
I'd love to be able to use Guitar Pro on my PPC. I'm unable to download this DGuitar file at the moment so I can't verify whether I can get it to work, but I will definitely be watching this thread.
please do, Im tempted to put a flash app together, since my Java skills are lacking. The Flash Lite platform is pretty good.
u should try this..
i think dguitar technically will work on your device together with java emulator software..
Unfortunatelly it's not so easy to convert Java SE (Swing) application to a J2MEE one. There are a lot of problems and as here we would need to convert both GUI and MIDI (sound) I think it's better to find an application predestined for PPC.
Maybe you could use Milktracker. Not exactly guitar but piano! http://www.milkytracker.net/
Or maybe :
MilkyPlay 0.9.7
MilkyPlay is a free module player for PocketPC supporting various formats.
Features:
- support for 669, AMS, AMF, CBA, DIGI, DSM, FAR, GDM, IMF, MOD,
MDL, MTM, MXM, OKT, PLM, PSM, PTM, S3M, STM, ULT, UNI and XM
- linear interpolation for better sample quality
- volume ramping for click removal
- audio visualisation
- nice GUI
- Song info viewer (instruments/samples/songmessage)
- playlists
- shuffle playback
- configurable button layout
- support for zip compressed modules)
http://peter.nxbone.net/MilkyPlay.zip
Not tried links recently.
Or maybe this link:
http://freewareppc.com/multimedia/pianonm.shtml
Or this other commercial one:
http://www.pocketpccity.com/software/pocketpc/Guitar-Fretboard-Addict-2005-12-16-ce-pocketpc.html
Sorry if I am barking up the wrong tree!
After recently coming across the open-source DGuitar project, I became interested in seeing if it was possible to port it to run on a win mobile JVM. As mjanek20 said earlier, the two major obstacles in doing this would be getting the Swing GUI components and the MIDI playback to work on these limited devices. The GUI components are actually not that big of an issue. On most WM devices, third-party JVM's (such as Creme) are available that support AWT and/or Swing components. The *really* difficult part is going to be the MIDI support. I've done a lot of research on this in the last few days, and I can't find any support (Java or otherwise) for low-level MIDI progamming. At best, there is support for playing back an entire MIDI file, but this is not appropriate for a Guitar-Pro viewer/player, where individual MIDI events need to be sent to the MIDI device in real-time. As I see it, there are three possibilties:
1) Substitute the MIDI events with simple tone events. This will give us basic sound, but we will be missing all the nifty effects like sliding, bending, hammer-on/off, fret noise, palm muting, etc.
2) Use a MIDI file exported from a GP file, and try to play this back in sync while displaying the tab in the GUI. Not sure how viable this is, just an idea at this point. I would hope it would solve some of the problems noted in solution 1, but syncronization and looping sections might be a problem here.
3) Program my own MIDI-to-PCM engine. I think some people have already done somethng like this (for instance, I am guessing the guys that came up with the Vibe MIDI sequencer midlet rolled their own), but unfortunately I havent found any open source, and frankly I'm too dumb and lazy to build something like this from scratch...so I'll probably start with solution 1 and then maybe see about implememnting solution 2.
I'll post my progress with the DGuitar port when I make a significant breakthru....if anybody else has any good ideas about a MIDI solution, let me know.
what is your progress with this? have you stop?
Hi,
So what is the actual progress?
I don`t really need the Midi playback, it would be perfect to just view the Tabs of a GP3, GP4 or GP5 File!!
Any other app around?
Regs
Sideburnt said:
Looking around the net I found a program called DGuitar which is supposed to be able to run on any platform with Java, I managed to get a .Jar file to play with but it doesn't install on my pocket PC (would have been a bit too easy eh)
Click to expand...
Click to collapse
DQuitar was written in Java indeed. But not in JavaME (ME stands for mobile edition) which is supported by most mobile phone. This is a huge different, and unfortunately DQuitar will not work on mobile devices.
Maybe it could be worth trying using JavaFX from Sun/Oracle while it's still available for our PPCs.
Jbed can run almost nothing where JavaFX behave correctly (except for on-the fly screen rotation). For instance, display is completely messed up using Jbed with Angry Birds, while the game is completely functional using JavaFX.
Quitar
Hello there,
I'm interested in developing image processing software for android devices. So far I got OpenCV and a simple example app running on my HTC Desire. It finds ellipses in realtime in a camera preview surface. The speed is OK (15 fps) and I expected the performance on the eeepad Transformer to be even faster. But the opposite is the case. The native (c++ implementation) camera preview that worked well on the Desire ist horribly slow on the transformer.
For me it's seems like the app has no full priority. Is there a way to give an app exclusive priority so it can use more CPU power? Are there some hidden performace switches on honeycomb I have to activate in order to get this app going faster?
thanks in advance for every answer or even hints to other forums.
SirHoop
I check the debug log of the native processor, apperently it processes the images with up to 30 fps. Unfortunately that is not the framerate I see on my display. This let's me conclude that there is a fundamental problem with the CameraPreview class on the transformer.
Apparently this is an OpenGL ES problem. The NativeCameraPreviewer of OpenCV uses a GLSurfaceView to draw the modified camera image. I use an additional GLSurfaceView to render some 3D content on top of that preview surface. So, 2 GLSurfaceViews are active and somehow that causes problems on either this specific device or android 3.0. On an HTC Desire running 2.2 this problem did not arise.
That's all I got, unfortunately I could not fix it so far. Just deactivating the second GLSurface made the camera preview smooth.
So, I've been at this for about 48 hours now (not continuously, but closer than you might think) and I figured I should take a break from modifying project files and puzzling over alignment issues to discuss the project, share some of the problems I've been having and ask if anybody can help, and so on.
The general idea is "Chromium build for Windows (on x86/x64) and build on ARM (for Linux), so there must be a way to build it for Windows on ARM". For the most part, that even looks like it's true. Probably at least 80% of 654 Visual Studio projects (no, that's not a joke) either build just fine with only minor amounts of work, or are things that we don't actually need (I'll try building the test suites... once everything else builds!!)
Areas that have given me problems (caution: some chance of brief rants ahead):
v8. Less than you might think, though. Setting the flags for Arm seems to have been enough.
Sandbox. There's a fair bit of thunking coded in assembly going on in the sandbox for x86. Not sure what's up with it (I don't know exactly how the Chromium sandbox works) but it'll have to come out or be replaced. The Linux (including ARM) sandbox seems to be SELinux-based, which doesn't help at all.
Native Client (NaCl). I think all the assembly is in test code, though, so I may just boldly #ifdef if all away.
libjpg-turbo (libjpg). Piles of carefully optimized assembly... for x86 and x64. There is a set of ARM assembly (for Linux) that Visual Studio won't compile, but something else might... or I may tweak until it works. Of course, I could also just accept the speed hit and use the version of libjpg implemented in nice, portable C.
Anything where the developers tried to use some SSE to speed things up. I may be able to replace it with NEON code, or I may just remove it and hope **** doesn't break. We'll see.
Inline assembly in general. Even when it's ARM assembly, Visual Studio / CL.exe don't want anything to do with it (__asm is apparently now an invalid keyword). I suspect I'll have to just pull the assembly out into stand-alone functions in their own files, then compile them to object files and link them back in later. If I can figure out the best way to do this (for example, I'll want to inline the asm functions) then it shouldn't impact performance. Seriously though, I kind of hate inline assembly. I can read assembly just fine, but I'm usually staring at it in a debugger or disassembly tool, not in the middle of source code I'm trying to build...
Everywhere that the current state of the CPU is cared about (exception and crash handlers, in particular) because the CONTEXT structure is, of course, CPU-specific. They're pretty easy to get past, though.
Low-level functions, like MemoryBarrier. Fortunately, it's implemented in ntdll.h... but as a macro, which breaks at least half the places it's referenced. Solution: where it breaks things, undefine the macro and just have it be an inline function that does what the macro did.
Running out of memory. Not even joking... well, OK, a little bit. I've got 32GB; I won't actually run out. Both Visual Studio and cl.exe do at times, though!. Task Manager says VS is currently using 1,928 MB, and before I restarted it, it broke 2.5GB private working set. Pretty good for a program that for some reason is still 32-bit...
Goddamn compiler flags. Seriously, every single project (I mentioned there are over 600, right?) has its LIBPATHs hardcoded to point at x86. Several projects have /D:_X86_ or similar (that's supposed to be set by the build tools, not the user, you idiots...) which plays merry hell with the #ifdef guards. Everything has /SAFESEH specified, not in the actual property table where the IDE could have removed it (unneeded and invlaid on ARM) but in the "extra stuff we'll pass on the build command line" field, which means every single .EXE/.DLL project must be modified or the linker will fail.
My current biggest goal is the JPG library; nobody wants to use a browser without it. After that, I'll tackle the sandbox, leaving NaCl for last... well, last before whatever else crops up.
Anyhow, thoughts/comments/advice are welcome... in the mean time, I'm going to go eat something (for the first time in ~22 hours) and then get some sleep.
Kudos for having the patience to look though this monster.
It's my understanding that NaCl is still a pretty niche thing at the moment. Is it possible to easily either disable it or completely hack it out, or do other more critical parts of Chromium now depend on it?
I don't think anything truly depends on it. I'll look in the VS dependency hierarchy and see how many things list it, and how awful it would be to remove them.. after I get the other stuff working. I may pass on the sandbox as well, if possible; it makes the security guy in me cringe something awful, but as they say, shipping is a feature..
great
Please make that happen !
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
GoodDayToDie said:
Working on it! I've gotten over half of the projects to build and link, but some other stuff is adamantly refusing to work. I'm beginning to suspect I'll need to work from the other direction - rather than starting at the bottom and building all the dependencies, then combining them into browser components, and then eventually combining all the components into a complete piece of software, I may have to work from the top, removing components until the whole thing builds (at which point it will likely be useless, or all-but) and then seeing what I can add back in. I thought it would be faster to just assume everything can be made to work and only exclude something if it proved intractable, but at this point I've got a ton of very small components and almost no ability to combine them.
It would also help if VS was better at managing such truly immense tasks. For example, I have no simple graph of what all is and is not building, so I'm being forced to manually map that onto the VS dependency tree and see what is blocking a given component from building successfully, and how much is dependent upon it, one erroring project at a time (and there are a *lot* of erroring projects - my last attempt to build any substantial part of the system saw 50 of 400 projects fail).
Click to expand...
Click to collapse
I thinkt tht is a mutch better taktic and mutch less frustrading.
I would love to see just a minimal version of it. After that all the small componens can follow.
50 of 400 is pretty good i think. Better then i expected
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
GoodDayToDie said:
Bear in mind that the entire thing is 650 projects. If 50 fail at that level, many of the higher-level ones (dependent upon the lower-level) will fail too. I'll see what I can do. I may or may not be able to get v8 actually working (without it, the JS speed will be very bad, think IE8 at best) and I may have to fall back to the legacy libjpeg (which will cut JPEG render speeds by at least a factor of 2). Skia (2D drawing library used by Chrome) has a bunch of assembly optimizations that I need to get it to use the Arm version of instead. There's a couple of total hacks with the library files I've had to pull, which may or may not result in a working final build. We'll see.
Click to expand...
Click to collapse
the v8 engine ( used in nodejs ) has been ported to ARM :
I still can't link : htt p://ww w.it-wars.com/article305/compiler-node-js-pour-arm-v5
perhaps it will help you
Edit : oups, I just see that another great user of this forum made the port of nodejs to RT
Yep... but they did it without v8. That's not an encouraging result, but I feel like I'm so close...
Is there a GitHub repo so we can help or track the progress of the project ?
Sorry, not at present. There probably should be. The sheer size of the codebase is incredible (about 2.4GB) and having some way to share it practically would be good.
Also, I suspect this would go a lot faster if I don't have to repeat the work of others. I know that there's a working Webkit DLL out there, for example (though with several features, including the V8 JS engine, missing) and if I could get my hands on that it would drastically reduce the number of additional components I need to build. Currently I'm working on the sandbux, but expect that I will need to rip the whole thing out and basically have the browser run as though it was always passed the --no-sandbox parameter, at least for the first build. Too damn much assembly.
http://www.engadget.com/2013/01/22/google-chrome-native-client-arm-support/
This wouldn't have any impact on this project, would it?
Sent from my SCH-I535 using xda-developers app, complete with annoying signatures.
It probably means that NaCl on Windows RT will be possible in the future. At present, I'm cutting it out of the build - too much x86-specific stuff there to port it over myself, and it owuldn't be able to run x86-compiled NaCl code anyhow.
You might have bit off more than you could chew. It'd better if you put your current progress under version control on some public site so that other people may be able to help you.
It's a big and complex project. You are taking a lot of time, and understandably so. But just open up to other people and you could get this done faster.
Yeah, this is probably true. My life also got unexpectedly *busy* in the last week; a couple weeks ago I had many times as much free time as I do now, and so porting has slowed down.
My upload speed would take ages (literally probably at least a day of solid activity; it's embarassingly slow) to push the full source anywhere, but I may make the effort anyhow. I'll have to post it somewhere for GPL compliance in any case...
You may upload only the diff files, they'll probably be smaller then the whole distribution.
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
I have personally jumped from IE8 > FF > Chrome and finally back to IE10 over the years depends on its usability, smoothness, speed, etc
Speed isn't the only reason to use a browser. I actually prefer IE myself, but there are some things that other browsers do better than it (in the case of Chrome, parts of HTML5, the syncing across Google services, etc.) Also, Chrome gets updated far more often than IE; IE9 was equal with Chrome on speed at its release, and was far behind by the time IE10 came out.
The reason for this project, though, is a mixture of interest in what it takes, and a desire to benefit the community. Microsoft has deeped that only software which they have blessed may run on the Windows RT desktop. I disagree, and have chosen (among several other things) to port a web browser because I feel that it's important for users to have choice.
LastBattle said:
Not to pour cold water on you however, IE10 is already faster than the latest Chrome build in Windows Phone, Windows 8.
I don't see the point of this.
Click to expand...
Click to collapse
Some websites do not get along with the trident rendering engine. Some webdevs are so "Oh f*** IE I don't care" and block access to features just because it is IE. I have experienced this first hand on IE10 on my surface where it tells me to come back when I have a decent browser, only to not have the choice to do that.
This really isn't the webdevs fault either, for years IE was the scum of the internet, only recently has IE caught up to the rest of the browsers (and in my opinion exceeded some) but the years of IE being bad have left a lot of disjointed webdevs who won't even consider giving the latest IE a chance.
Only created my account today, so I don't have enough posts to put this in the developer section. Maybe someone can help me out.
I managed to get the Quake2 source from Ids ftp server to build (with a lot of warnings) for ARM in Visual Studio 2012.
I've attached a screen shot and the binaries to this post.
All you need to do is drop the pak0.pak and players folder into baseq2.
Enjoy!
EDIT: should also mention that this is a native port (not .net or winrt) -- props to XDA guys for the hack!
EDIT2: for those with errors, keep in mind you need the pak files and players folder from the quake2 install for this to work (or you can grab them from the demo). Google is your friend! . If you encounter the famous "water crash" then run "sw_waterwarp 0" in the quake console.
EDIT3: For a joke. I've added the OpenGL Quake2 renderer and a software based OpenGL implementation (built from an older version of Mesa3D) as attachments. Given that Windows RT doesn't have support for OpenGL this is probably as good as its going to get without a port that has Direct3D support. While the OpenGL version looks much better, be warned.. it runs __very__ slow. If you want to give it a try, just go into video options and change the 'driver' option to "default opengl". Enjoy!
EDIT4: So.. in an effort to clean up some of the bugs, I stumbled upon KMQuakeII which has an 'unofficial' 3.23 patch for the Quake 2 source. I've managed to compile that version of the source for ARM. I was hoping this would fix the full screen issues, but it didn't. Regardless, there are probably worthwhile bug fixes anyway.. so I'm posting it here. There are also extra video modes in this version (very easy to add btw!) however the 1366x768 mode didn't work correctly on my Surface.
Well done! Link added to the list. Much appreciated...
bfosterjr said:
Only created my account today, so I don't have enough posts to put this in the developer section. Maybe someone can help me out.
I managed to get the Quake2 source from Ids ftp server to build (with a lot of warnings) for ARM in Visual Studio 2012.
I've attached a screen shot and the binaries to this post.
All you need to do is drop the pak0.pak and players folder into baseq2.
Enjoy!
EDIT: should also mention that this is a native port (not .net or winrt) -- props to XDA guys for the hack!
Click to expand...
Click to collapse
cool, seems to run nicely, -just using one core.
At first : Thanks for the work!
But i get an Error :"Couldn't load pics/colormap.pcx
(on Surface Jailbrocken)
I can't manage to open it. It says there is an error.
Another question... I want to do it for Bluestacks. Do you know anyone that could've done this? Thank you.
save_jeff said:
At first : Thanks for the work!
But i get an Error :"Couldn't load pics/colormap.pcx
(on Surface Jailbrocken)
Click to expand...
Click to collapse
Make sure you have the pak files and players folder from your quake2 install in the baseq2 folder. If you don't own quake2 then you can grab these files from the quake2 demo install (google for it). Good luck!
Awesome job!
I got mine working smoothly
There is some issues that often when I load saves the game crashed (quake2.exe has stopped working)
I have no idea. Save game works perfectly and start new game works as well.
Looks like this guy back in 2005 have the same problem (except he is using... Amiga?): ht tp://eab.abime.net/showthread.php?t=17808
Tanks i did not know that ;]
I Will get a Demo right now ans try ist.
Does it work with any Version of quake II ?
---------- Post added at 10:54 PM ---------- Previous post was at 10:29 PM ----------
Okay now it works like a charm! Realy impressiv
shog7n said:
Awesome job!
I got mine working smoothly
There is some issues that often when I load saves the game crashed (quake2.exe has stopped working)
I have no idea. Save game works perfectly and start new game works as well.
Looks like this guy back in 2005 have the same problem (except he is using... Amiga?): ht tp://eab.abime.net/showthread.php?t=17808
Click to expand...
Click to collapse
Yeah, there could be several bugs in it. This is built straight from iD's source. There are many other 'ports' of quake2 that have encountered and (in some cases) fixed various bugs. Still, its extremely playable even with a few annoying bugs!
I cant get mine to go to full screen.... is this usual behaviour?
advancedservers said:
I cant get mine to go to full screen.... is this usual behaviour?
Click to expand...
Click to collapse
Yep. The pure Quake2 source has known issues with full screen on "odd" resolutions. Given the time frame for when Quake2 was developed.. the 1366 x 786 resolution that is common today doesn't make any sense that's why its "not supported". There were some unofficial patches added to Quake2 many years ago to add wide screen support and more resolutions. A lot of people also fixed the problem by just using the OpenGL version (which I could also provide binaries for.. but its _dog_ slow). What I've ported here is the 'software render' which got very little attention once the '3d boom' hit. If I get bored, I may see if I can get full screen working in the software renderer.
Joystick or Xbox Controller?
App is cool and runs well with mouse or keyboard but I have tried joystick and Xbox controller (both recognised by WinRT) and app ignores both. I have turned on Joystick under options.
I didnt get any bugs yet.
But Fullscreen would be nice
Woww this game bring me so many good memories nice work!!!
advancedservers said:
I cant get mine to go to full screen.... is this usual behaviour?
Click to expand...
Click to collapse
Same here. 800x600 is the best resolution to me..
Btw can you load your saves after close the game and restart it?
For what its worth, I've updated the original post with 'newer' binaries and software based OpenGL support. The fullscreen thing is also bothering me so I'll put some effort into that over the next couple days -- hopefully its been fixed in a different Quake2 port and I just need to migrate the code over. Cheers!
If you don't mind me asking where did you get the source files from? I would have done this two days ago but I couldn't open the project files from id's github. I then tried quake 3 and doom 3 but getting those working is a different problem entirely. Those games have inline assembly in them that I don't have the skill to replace.
johnnyfives12 said:
If you don't mind me asking where did you get the source files from? I would have done this two days ago but I couldn't open the project files from id's github. I then tried quake 3 and doom 3 but getting those working is a different problem entirely. Those games have inline assembly in them that I don't have the skill to replace.
Click to expand...
Click to collapse
The source came straight from ftp.idsoftware.com. There is a lot of pain in getting a working vs2012 solution file and convincing the source that Win32 does not imply x86! Many issues with libs and older CRT functions too. Just takes time, patience and good experience with VS & C code.
You're absolutely right about Q3 or Doom3. They will require an overhaul and will need to be ported to Direct3D10+. Sadly I don't have the spare time to get _that_ involved -- though I'm happy to help if someone wants to lead the charge.
Cheers
Game crashes sometimes when I try to load a saved game. Also performance is far from what I expected. I remember playing it on my Nokia n95 with software renderer and it was fluid, on surface higher resolutions cause serious performance degradation. The more I use desktop apps ported to Windows RT(quake, dosbox) the more I think that tegra 3 suck.
bartekxyz said:
Game crashes sometimes when I try to load a saved game. Also performance is far from what I expected. I remember playing it on my Nokia n95 with software renderer and it was fluid, on surface higher resolutions cause serious performance degradation. The more I use desktop apps ported to Windows RT(quake, dosbox) the more I think that tegra 3 suck.
Click to expand...
Click to collapse
Same loading problem here...
But it runs pretty fluid on my Surface...