Forum Replies Created
-
Posts
-
Well, third way is really only widget.
Sorry for this brainstorming, I need it…
If we focus on widget, what it will do? We must think in MS-DOS programming. You need to implement the ability to look up, down, turn to right and left. Plus fire.
Fire is single keyboard/gamepad button. This is easy, it starts fire when you touch widget (ON_TOUCH_DOWN) and ends on widget’s event ON_TOUCH_UP. Easy.
Now, turn to left/right, aim up/down. How these actions can be performed in MS-DOS duke3d? Axis, mouse, keyboard, ….
Please write what do you expect.
I agree, playing duke on your video looks cool. I am interested, but I am slow programmer, some things takes me long time. And implementing this is not work for 3-4 hours. I really need get familiar with these controls.
First idea was that I can add new flag “passthrough” to general widget’s properties. This means, that finger events will not be catched by first founded widget, but will continue down through widget’s tree to the main surface where you control mouse. But probably inside widget you will need process mouse events (or axis) on different speed (for better aim). This makes a lot of complications.
Another idea was implement completely new control schema according to beloko’s with possibility switch between schemas in general settings. Current schema is very complicated due gestures and various widget events. Having new “light” schema, without gestures would be at the end easier way.
Both has advantages and disadvantage, takes a lot of time and cannot be done from recording. I must play and think about during gameplay
And where can I buy that duke3d app which you use in video? I was searching on web but without success…
Thank you. I only implemented good ideas of many people.
Widgets remembers initial orientation and stays in this orientation even you rotate device. This way it was designed from beginning and prevents many problems.
Current version 62 has bug which is there long time, sometimes on startup are widgets loaded in incorrect orientation, but I did not worked on that, because simple restart fixes it. But now, due immersive mode I rewrote some stuff and it will work correctly. This is related to that problem with right side described by you.
Walkthrough widget uses WebView control provided by android system (you can update it through google play). In reality it is simple web web browser. This supports txt files well (and probably images too), I can look at this. I am not sure about pdf. I will look at this in free time.
Yes, I know switching layers action is not very intuitive, I got several warning from users. I will think about it.
I found that problem now when I implemented true fullscreen mode. It is magic dosbox bug. I save screen size at startup and on orientation change, but navigation bar hides a bit later, so screen size is not updated. Game texture is updated a bit different way. If there will be no other problems then it will be fixed in next version.
Hi,
Please could you make video, I like to see it. This is really weird.
True fullscreen mode (immersive) is not now supported, but it should be in next version
No, it cannot work this way. Installing win95 is complicated. At beginning you need HDD image. Then win95 bootable cd. In limbo you mount hdd and cd. Then you install win95 to this hdd.
This video is for old limbo, but may help you
It is not tutorial on few lines 🙁 If you want make it on android then pick limbo pc emulator, should work better.
Yes, that makes sense. In the future I want implement possibility to bind some action to wheel up/down. Now I work hardly on console mode which can access magic dosbox on android tv
