Our New Machine, Pandora

[Squidge]

I'd say it's too early to decide on software issues such as debian packages, the custom menu/etc. Leave it until next year (or just go ahead and make your own for the 2x, and then port to the new console upon release).

GP2X: no opengl, so no port


Why do you need OpenGL for a menu system?

 

[Nr.56]

So, as we say in Spanish, I'll kill two birds with one shot :lol:

Hi,

It's funny, it's "A stone two birds" in English, and "Une pierre deux coups" in French, which has quite the same meaning. It seems that our planet Earth is getting smaller everyday
...
Magic Sam


two flies on one stroke .... the german version
(not the same but very similar!)

 

[efegea]

Why do you need OpenGL for a menu system?

2D Acceleration (more fluid), animations, compiz-like effects, a lot of things

EDIT: oh, and bilinear filtering for free! don't you want that on a image viewer? My menu will have one

 

[Squidge]

What's wrong with a simple fingertip control (IPhone like)? Why should i have to use the stylus if i want to open SquidgeSNes wich makes no use of it?
The startup screen should only constist of icons of the three last used programms and (maybe) 5 favorits. Also programs like mp3 players shouldnt (maybe with exception of the options menu) make use of the stylus. Fingertip or direct button control are the better solutions for sure. Just a note to think about...
:unsure:

If the selections are big enough, surely it would be up to the user to chose between stylus and finger tip? I prefer using my finger, as I don't want the bother of searching where I lost the stylus. Some people prefer stylus however as they don't like the smudge marks that greasy fingers give.

Oh, and SS will make use of the touch screen, well, until your actually playing a game that is (then it'll probably only be used to bring up the in-game menu). Touch screen is so much easier and faster than messing around with arrow and action keys.

 

[A_SN]

Why do you need OpenGL for a menu system?

2D Acceleration (more fluid), animations, compiz-like effects, a lot of things

I'm probably asking this out of ignorance, but how is OpenGL better/faster than SDL when it comes to 2D stuff?

 

[efegea]

Why do you need OpenGL for a menu system?

2D Acceleration (more fluid), animations, compiz-like effects, a lot of things

I'm probably asking this out of ignorance, but how is OpenGL better/faster than SDL when it comes to 2D stuff?


Because all operations are done in hardware. Scaling is free on opengl while very cpu intensive when doing on SDL. The same for bilinear filtering. And also the special effects using pixel and vertex shaders.

 

[A_SN]

Scaling is free on opengl while very cpu intensive when doing on SDL.

And why couldn't SDL hit the hardware to do that?

 

[efegea]

Scaling is free on opengl while very cpu intensive when doing on SDL.

And why couldn't SDL hit the hardware to do that?


Because it should use the 3D hardware, and SDL is not capable to do it, it only uses 2D acceleration

Unless you are talking about SDL-OpenGL, which is what I am using

 

[Vince2501]

It is all complete we just don't want to release anything until we are ready.

Pictures - Videos - Specs - Prototypes to devs - Preorders - Release

We have a goal of around Mar/April for the final systems to be shipping out. Some devs are getting PCBs in the next week or two.

This isn't a dream or a fanboy system (as some people keep saying) - it's real.

h34r:

Definitely going to buy this. Hopefully I can get some good deals with SD cards over 4 Gigs. DS emulation, CPS3 emulation (a given at this point) and Quake 3 (and by Default Unreal Tournament) plus the distinct possibility of PSP and Saturn emulation have sealed the deal for me. As for Dreamcast.... I'm not going to hold my breath on that one, but I get the feeling it may be possible if not now then later on when Null DC and that Linux emu become more and more refined. Ya' never know.

Side questions:

Would it be fairly simple to develop a game for this system? I mean, would you need an depth knowledge of C++ or something similar to get it going? I would also like to see some easy to work with game engines developed for the various genres (such as Beats of Rage) I get the impression that Mugen or a Mugen-clone could be ported. But I'd like to see Run 'N Gun, Platforming, and Shoot 'em up engines created at some point.

A peripheral question: Is or would there be developed at some point in time an adapter to plug the unit into a car lighter or something and play music through your vehicle?

 

[A_SN]

The startup screen should only constist of icons of the three last used programms

Bad idea, really. I know it's a minor detail, but having an inconsistent element in an interface is a mistake to avoid.

 

[gaterooze]

re: GUI variations. How about one with a ring system where you can drag your finger/stylus around the edge to change the icons on screen (kinda like jog control). The ring can be split into different categories, and can also be tapped in each segment for instant access.

 

[Nr.56]

...
If the selections are big enough, surely it would be up to the user to chose between stylus and finger tip? I prefer using my finger, as I don't want the bother of searching where I lost the stylus. Some people prefer stylus however as they don't like the smudge marks that greasy fingers give.

Oh, and SS will make use of the touch screen, well, until your actually playing a game that is (then it'll probably only be used to bring up the in-game menu). Touch screen is so much easier and faster than messing around with arrow and action keys.

bad example... <_<

A new one: All settings of the emu are done. A large icon suitable for fingertip is on the start screen. This icon is named "Mario Kart". You want to play "Mario Kart". Oh happy day, I have not to grope for my stylus. I use my finger and play "Mario Kart"!! :lol:
like you posted before: the size matters!
I think 75% of cases the same programs or games will be started wich were opened before. Therefore I would prefer a start screen with large icons of the last programs and some favorites. The whole desktop occurs after pressing a button (if needed). bad idea??

PS: @GunPei2X: turning icons are a oportunity, i like it

 

[morrissey2k7]

Why hasn't this thread been moved? It doesn't belong in General GP2X Talk AT ALL.

There's already one overly bloated thread about this ("Our New Machine"). We really don't need TWO.

<_<

 

[Exophase]

Scaling is free on opengl while very cpu intensive when doing on SDL.

And why couldn't SDL hit the hardware to do that?


SDL just doesn't officially have the facilities for scaling (or other linear transformations) at all. If it did then it could. Some SDL implementations for devices with fixed resolutions (like all handhelds) will apply a hardware scale to screen surfaces that don't match the resolution, though.

Someone tell me if this has changed recently, I wouldn't know.

 

[Vilmos]

QUOTE

They are not? Well Rlyeh, Squidge, Pepone, DJWillis, Zodttd, Vilmos, Guyfawkes etc. have all jumped on the bandwagon. That seems like alot to me, more than just paranoia. But like I said it will still just be a flash in the pan as when the Craiginator is released I can't see there being much support for it anymore.



Sorry bit late, just saw this. I am not abandoning the gp2x for the JXD thingy, just playing around with it, assuming it ever arrives that is.

I've been too busy at work to even load up my dev machine for the last two months!

I'm hopeful to get some fun stuff done over my holidays at Christmas. Finish up Thruster the way I meant it to be and then start on something new.

 

[Squidge]

How come people are constantly asking for UT to be ported? I know the game itself was excellent, but all I've ever seen published is the windows game source code (basically the gui, input and stuff to talk to the game engine) and nothing for the game engine itself.

If that is still so, it could be recompiled and ported to any system as long as it's x86 (as the game engine was/is x86 object code only).

As for OpenGL, yes, that would offer far more flexibility than SDL for 2D stuff. You could basically just map a frame buffer onto the face of a cube and then rotate, size, etc all in hardware. Actually, having each app on the face of a cube would be quite nice as an application switcher

 

[Squidge]

Anyone got an iPhone/iTouch? What happens when you fill the startup screen full of icons - does it then scroll vertically, or does something funky happen?

What I was thinking of is that if you had a screen full of icons, you could simply touch and drag an icon-free part of the screen (say, the space between icons/etc) it would move all the icons up or down. If you move you finger slowly up the screen, it was scroll slowly, but if you quickly moved your finger up/down the screen and then released, it would quickly scroll before slowing down to a stand still.

In other words, let steal how Apple do it on the iTouch/iPhone (I really do like it's user interface)

 

[Squidge]

They are not? Well Rlyeh, Squidge, Pepone, DJWillis, Zodttd, Vilmos, Guyfawkes etc. have all jumped on the bandwagon. That seems like alot to me, more than just paranoia. But like I said it will still just be a flash in the pan as when the Craiginator is released I can't see there being much support for it anymore.

I think you'll find out that most of us have shown a "passing interest", but little else. For me, the novelty has already worn off and I don't even have it yet.

 

[StealthBagel]

SDL just doesn't officially have the facilities for scaling (or other linear transformations) at all. If it did then it could. Some SDL implementations for devices with fixed resolutions (like all handhelds) will apply a hardware scale to screen surfaces that don't match the resolution, though.

Someone tell me if this has changed recently, I wouldn't know.

There's the SDL_GFX library that supports rotation and scaling of surfaces but it's software, I don't think it can be used with a GPU without extensive modification and you might as well write something else anyway by that point..... but the way I see it, these are the critical pieces of functionality that should be accelerated via the GPU from SDL as they'd encompass the vast majority of SDL apps past present and future:

1. Making hardware surfaces in vram
2. Blitting from surface to screen (supported on GP2X, makes some improvement but not a whole lot)
3. Blitting from surface to surface in vram (I'd call this the most important)
4. Filling rects with a color
5. Alpha transparency

Things that would be extremely helpful if accelerated:
1. Image decompression and conversion to display format (like uncompressed 16bit, 24bit or 32bit pixmaps depending on the screen color depth, which I don't think has been revealed yet.... just resolution)

2. Rotation and scaling of surfaces, ideally using blending or filtering to antialias the result

The way I see it, it's extremely important all major 2D acceleration tasks be supported right away with the new handheld from SDL, requiring the use of openGL will put more burden on developers and people wanting to port existing software that doesn't already use it. A community member like Paeryn shouldn't have to donate lib later, it should just be supported from day 1 with the SDK.... what shipped with the gp2x was a bit on the mediocre side IMHO; any aspiring developer for the system should have all they need to get started from the minute they open the box.

It would also be a big deal to me if USB networking like the gp2x f100 had was implemented; it's a damn shame gph took it out in f200 because it was honestly the best idea they ever had. Running telnet on my PC and running apps on the handheld from a commandline was invaluable whenever I wanted to test some small change and not have to swap my SD card in and out of my PC, reset the device, etc.

 

[StealthBagel]

We really need another forum for different topics about this machine, you can't find anything useful in here with so many conversations and sub-sub-conversations going on...... there needs to be threads for interface, CPU, GPU, emulators 'what's possible and what's not', porting apps, development, other hardware design ideas, controls, etc..... I mean you can't even tell someone asking questions that were already asked "read the thread" because it's over 200 freakin pages.... not to mention all the embedded flamewars in here.