new branch - CHDK : Elf Edition - Developers wanted - page 10 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 32   Go Down

new branch - CHDK : Elf Edition - Developers wanted

  • 316 Replies
  • 140350 Views
*

Offline outslider

  • *****
  • 762
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #90 on: 19 / December / 2011, 17:13:53 »
Advertisements
Quote from: tsvstar on 19 / December / 2011, 15:09:25
Quote from: philmoz on 19 / December / 2011, 14:14:57
For example the game code gets compiled with the color palette definitions from gui_draw.h - this may work on other cameras using the same palette; but not cameras using different palettes.
I miss that fact. I thought that simple colors are same for all cameras.
This could be significant difficult on the way to platform-independency because affect almost all modules.
About colors and other camera-dependend values. Maybe functions in different modules could use special parameters to somehow share this values? I guess I'm not really clear, but my idea is as follows:

- main CHDK module, which is loaded at start have been compiled with some compiler-defined values, such as colors (obviously)
- user wants to play Tetris, so main binay loads a module
- module have no idea about colors, that are compiled into main module and could not use colors (that's bad)

so loaded module should ask the main binary about values it needs. Main module could have a few specific functions that return some camera-dependend values when module run these functions.

I'm not sure it's clear. And I don't know this is a good way. I'm not a programmer, so this is just an idea...
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #91 on: 19 / December / 2011, 17:23:55 »
Quote from: outslider on 19 / December / 2011, 17:13:53
Quote from: tsvstar on 19 / December / 2011, 15:09:25
Quote from: philmoz on 19 / December / 2011, 14:14:57
For example the game code gets compiled with the color palette definitions from gui_draw.h - this may work on other cameras using the same palette; but not cameras using different palettes.
I miss that fact. I thought that simple colors are same for all cameras.
This could be significant difficult on the way to platform-independency because affect almost all modules.
About colors and other camera-dependend values. Maybe functions in different modules could use special parameters to somehow share this values? I guess I'm not really clear, but my idea is as follows:

- main CHDK module, which is loaded at start have been compiled with some compiler-defined values, such as colors (obviously)
- user wants to play Tetris, so main binay loads a module
- module have no idea about colors, that are compiled into main module and could not use colors (that's bad)

so loaded module should ask the main binary about values it needs. Main module could have a few specific functions that return some camera-dependend values when module run these functions.

I'm not sure it's clear. And I don't know this is a good way. I'm not a programmer, so this is just an idea...

Colors is just one example - there are many things defined and conditionally compiled at build time that would need to be converted to run time code in order to support portable modules. Look at all the things defined in camera.h / platform_camera.h. DNG support might be a good candidate for a module; but it has a lot of camera specific settings in platform_camera.h. Making all of those runtime instead of compile time values may increase the CHDK size and could affect performance - needs to be done carefully.

The color/palette handling system needs a complete overhaul; but it will be complex, in part due to the fact that colors are stored in the CCHDK.CFG file.

As I said having portable modules would be a good thing; but is it the right area to focus a lot of effort on now. Getting the core module system working and stable and converting more code into modules would be my priority. Then start looking at what else needs fixing for portability.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline outslider

  • *****
  • 762
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #92 on: 19 / December / 2011, 17:30:43 »
Sure, without the core the whole system with all ideas is useless... It would be as GNU before Linux ;)

I know, that colors are only an example and I used this example. But there could be many functions that return all these values we actually have in camera.h. and platform_camera.h. Even if this would take a lot of binary size it will be still smaller than whole CHDK at now. And adding these command shouldn't be a really problem, if the core will be created (I guess so).

I keep my fingers crossed for the whole Elf edition and I'm sure it will bring a lot of new possibilities. Maybe we don't even know, how many!
Logged
if (2*b || !2*b) {
    cout<<question
}

Compile error: poor Yorick
*

Offline tsvstar

  • ***
  • 231
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #93 on: 20 / December / 2011, 02:25:42 »
Main question of last discussion is: Should modules be platform-independent in cost of some increasing of internal complexity or not, and what possible other impact exists.

My vote - yes, they should. And my thinks are below

2Microfunguy:
Sure. Enduser never will know what happens inside.

2outslider:
This is exactly as it works now. Any variable or function could be clearly with no effort shared with modules.
To share define/constant I need just declare global variable, assign value to it and share variable. Easy.
They have only two difficulties:
- conditional compiling should be avoided or used some tricks.
- not obvious naming in exportlist for them.

2Philmoz,
Thanks to notify about palette issue. And will be appretiate for notify about other platform dependend things (except platform.h/camera.h).

But I do not agree with many of your thesises.
a) We can make any part of CHDK which is strongly based on platform - platform dependent. But I don't think that this is should be reason to make all modules platform-dependent

b) Regarding to need export "everything" from camera.h/platform.h. We don't need to do that. Not all symbols are shared now, but only required to modules. Same things with defines from this header files (variable will never be a problem).

c) About two _rawop modules. I realy don't think that 3kb size and 1sec of compilation is a problem. For end user simple rule exists - "copy everything". So he should know nothing about details.
BTW, currently on PC same things exists every day. When some driver/software installed - binaries for all possible cases are copied but used only one of them.
Main reason of current implementation of rawop was minimize changes in raw_merge.c to avoid possible bugs.

d) Regarding to perfomance impact. I think that this should be discussed on practice for exact modules.
I don't investigate DNG module closely. On first look it have really strong dependency and integration. So probably it could be platform dependent. But it surely need to be tested what size/perfomance impact will cost independency.
For now I know that raw operation module use a lot of platform-dependent things and it is now made as platform-independent module. Now no perfomance impact exists at all. On my trunk CHDK raw sum of four RAWs take 56sec, and same raw sum on same RAWs with rawop module take same 56sec.

e) Regarding to palette. I already solved this issue in my private build. I will push it into repository after some testing. Below is compare list of binaries. As you can see palette costed ~200byte in core + up to ~200byte in game modules.

OLD         NEW
217121    217265    DISKBOOT.BIN
  4960      5184    4wins.flt
  2536      2664    benchm.flt
  2520      2676    calend.flt
  2836      2836    curves.flt
  4436      4436    edgeovr.flt
 10924     11024    fselect.flt
  2592      2832    mastmind.flt
  1580      1760    memview.flt
  1264      1344    modinsp.flt
  2036      2036    modmenu.flt
  1288      1336    mpopup.flt
  1152      1204    palette.flt
  3920      4116    reversi.flt
  8768      8864    snake.flt
  5792      5928    sokoban.flt
  8128      8256    tetris.flt
  3408      3456    txtread.flt
  3716      3716    _rawop10.flt
  3292      3292    _rawop12.flt
« Last Edit: 20 / December / 2011, 03:44:40 by tsvstar »
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #94 on: 20 / December / 2011, 04:20:37 »
Quote from: tsvstar on 20 / December / 2011, 02:25:42

c) About two _rawop modules. I realy don't think that 3kb size and 1sec of compilation is a problem. For end user simple rule exists - "copy everything". So he should know nothing about details.
BTW, currently on PC same things exists every day. When some driver/software installed - binaries for all possible cases are copied but used only one of them.
Main reason of current implementation of rawop was minimize changes in raw_merge.c to avoid possible bugs.


Multiply that by 160+ cameras in the autobuild

Just because Microsoft is lazy doesn't mean we should be - we also don't have anywhere near the available resources of a modern PC.

I'm still not convinced two versions of _rawop is the best solution, in my view a single .flt file would be better.
- if it's platform dependent then compile it with the correct bit depth for the camera
- if you make it platform independent then check the bit depth at runtime and select the appropriate code path.

Ultimately it's your code and not really a big issue, if you want to do it as two files it's your decision.

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline tsvstar

  • ***
  • 231
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #95 on: 21 / December / 2011, 11:42:22 »
Big update of  flat module branch:

Rev1493:
- Reconcile to trunk1492
- Improve usermenu to store menuitems absent in .lng as hash (better processing "modules" menu)
- Improve core auto-versioning (use x.xx.xx instead of revision to compare module requirement.this allow to compile-from-box)
- Improve module load checks (cancel load if autoimport symbol is empty [allow auto control if module base on obsolete chdk mechanizm])
- Improve makeexport to simplify sharing defines from core to modules
- Separate module_exportlist.c compilation

Rev1494: Making modules truly platform independent
- Isolate palette colors
- Isolate platform-dependend IO functions/structures
- A lot of small isolations: DNG, key_erase/display, platformname
- Replace in existed exportlist unsafe functions with safe variant(*)
- Extend module_info.required_ver for future (*)

Now it should compiled "from box".

New modules are incompatible with previous revision (use benefit of "development" state to avoid unnecessary enlarging :) )

Few modules different cameras are still binary different for different cameras, but looking to objdump reason is just different order of some operators with exactly same result (strange optimizer work?).
Now modules should be truly platform independent. Thanks philmoz to take my attention to fact that before modules was not really independent (I thought they are).
Logged
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #96 on: 21 / December / 2011, 12:58:07 »
@tsvstar : I think you need to delete these lines from reyalp-flt/Makefile :
 
Code: [Select]
zip -9 $(topdir)bin/$(PLATFORM)-$(PLATFORMSUB)-$(BUILD_NUMBER)-full$(STATE).zip $(topdir)CHDK/SCRIPTS/4Pack/* > $(DEVNULL)
zip -9 $(topdir)bin/$(PLATFORM)-$(PLATFORMSUB)-$(BUILD_NUMBER)-full$(STATE).zip $(topdir)CHDK/SCRIPTS/4Pack/Lua/* > $(DEVNULL)
zip -9 $(topdir)bin/$(PLATFORM)-$(PLATFORMSUB)-$(BUILD_NUMBER)-full$(STATE).zip $(topdir)CHDK/SCRIPTS/4Pack/uBasic/* > $(DEVNULL)
We got rid of that directory due to path length issues with some versions of DryOS.

Update : I see that the Module Inspector and Benchmark both come up with a white screen on my G10.  I assume that means its white text on a white background ?
« Last Edit: 21 / December / 2011, 13:13:02 by waterwingz »
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline whim

  • ******
  • 2046
  • A495/590/620/630 ixus70/115/220/230/300/870 S95
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #97 on: 21 / December / 2011, 13:38:07 »
@tsvstar

I can confirm that with waterwingz' mods reyalp-flt1494 compiles fine (no warnings)
However, running my ixus220_elph300hs (100c) with it, I managed to crash the 'Module Inspector' module.
Other modules load/unload fine, but Inspector quickly flashes something like ' ... failed to load ...' then crashes the cam.
Dumping produces attached ROMLOG.LOG

Off to check on a VxWorks cam now,

wim

Edit: VxWorks seems to be a little more resilient: no crash (cam shuts down after ~20 sec)
         "Fail to load MODINSP.FLT : bad import symbol" (ixus70_sd1000-100b)
« Last Edit: 21 / December / 2011, 13:59:29 by whim »
Logged
*

Offline tsvstar

  • ***
  • 231
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #98 on: 21 / December / 2011, 14:45:36 »
waterwingz,
1. Please check what happens with calendar.  Are there white background?
2. Please try to load revision1493 - are benchmark have same mistake? If you need I can attach undo patch.

whim,
1. Where can I read how to find useful info in romlog? Unfortunatelly I'm not familiar with this. :(
2. Please comment in module_inspector.c lines from
      if (_getmeminfo) {
and till closing bracket. Are modules still crashed?
UPDATE: this item should be fixed with 1495 revision. should load ok
3. Are your cameras shutdown if you try to run old modules (copy one of old *.flt modules to anywhere on card, run file browser, just press "set" on this file)
4. Is 1493revision have same problem?
« Last Edit: 21 / December / 2011, 16:11:09 by tsvstar »
Logged
*

Offline tsvstar

  • ***
  • 231
Re: new branch - CHDK : Elf Edition - Developers wanted
« Reply #99 on: 21 / December / 2011, 15:58:19 »
Posted Rev1495 quick fix recent problems with module_inspector and warnings.

waterwings,
could you also please check how benchmark work in last trunk(1492).
Logged
Pages: 1 ... 5 6 7 8 9 [10] 11 12 13 14 15 ... 32   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal