scripts not cross platform

[verdra]

this project can't easily be run in a linux environment. it would be nice to have a python entry point rather than a batch script entry point.

[verdra]

i can right a quick replacement for the batch scripts, but i think the main.py could be refactored as well.

[cff29546]

this project can't easily be run in a linux environment. it would be nice to have a python entry point rather than a batch script entry point.

Can you roughly describe how you would refactor the code or what design pattern would follow? You can also post PRs to explain your idea.

[verdra]

the basic one i have going involves using a ini file for the config and configparser to read it in, figured that would be easy for windows users to edit. then a run.py file takes a few flags an subprocess to replicate the man batch files.

not sure what i am going to do with main.py yet, going to have to give a look over it over the weekend.

[cff29546]

the basic one i have going involves using a ini file for the config and configparser to read it in, figured that would be easy for windows users to edit. then a run.py file takes a few flags an subprocess to replicate the man batch files.

not sure what i am going to do with main.py yet, going to have to give a look over it over the weekend.

Sounds good, we can talk when you have a detailed plan.

[verdra]

ok so what i am thinking is

1. get rid of render.py and bring the dict into main.py
2. move copy html folder in main.py
3. move texture unpacking into main.py. not sure how to handle multiple additional texture packs just yet.
4. move a lot of the config file to defaults in the argparse section, may be completely get rid of it and just use args
5. break up the add_arguments and store them in their respective scripts
6. use parse_known_args to grab information about (top, iso, or both) and (specific layer or all layers) to then grab the appropriate args from step 2
7. redo the process function, probably a complete rework

you would call the script like python top full -o $OUT_PATH -t $TEXTURE_PATH -z $MAP_PATH ... other_args

that's what i am thinking so far

any comments?

[cff29546]

ok so what i am thinking is

1. get rid of render.py and bring the dict into main.py
2. move copy html folder in main.py
3. move texture unpacking into main.py. not sure how to handle multiple additional texture packs just yet.
4. move a lot of the config file to defaults in the argparse section, may be completely get rid of it and just use args
5. break up the add_arguments and store them in their respective scripts
6. use parse_known_args to grab information about (top, iso, or both) and (specific layer or all layers) to then grab the appropriate args from step 2
7. redo the process function, probably a complete rework

you would call the script like python top full -o $OUT_PATH -t $TEXTURE_PATH -z $MAP_PATH ... other_args

that's what i am thinking so far

any comments?

It looks good besides 2 and 3. The concern about 2 and 3 is that sometimes I only want to run a single render task, especially in testing. For example, render the base map only at the beginning and add the population heatmap later. I can skip copy html and unpack texture steps when I add the population heatmap later. If these steps go into the main.py, it will require either some skip flags or some logic to judge if these steps are needed.

[verdra]

yeah, i was planning a adding logic to skip if they were unneeded.

also, as a separate thing from enabling this to run with just python, i was thinking about making the render scripts to be run independently. but that is out of scope for this issue.

[cff29546]

yeah, i was planning a adding logic to skip if they were unneeded.

also, as a separate thing from enabling this to run with just python, i was thinking about making the render scripts to be run independently. but that is out of scope for this issue.

Do you mean running render tasks in parallel? In the current code base, you can execute multiple render tasks in the script/ folder simultaneously to achieve this. But if you change main.py to handle all render tasks, you will support parallel explicitly.

[verdra]

no i didn't want to mess with the internals of the rendering.

i was just thinking of moving some of the components around or adding some imports so that you could run zombie.py. i guess you could then run all the scripts in parallel but why would you?

i just think being able to running the layers and base steps independent from what ever is going on in main would be good for testing.

but again that is for later and is out of scope for what i am doing now. i may not even get around to it.

[cff29546]

In a previous iteration of this project, rendering was performed layer by layer, with each task (such as room, zombie, and base) having its own Python executable and process() logic. However, due to the varying processing logic required by each task, optimizing the project as a whole was challenging. Additionally, adding new tasks was cumbersome because it required writing similar argument parsing and processing logic for each new task executable. To address these issues, I unified the task render framework to enable sharing of the render and pyramid-building logic across tasks. Each task now only needs to implement the interface for rendering a single square or tile, similar to a shader in modern 3D games. This approach decouples tasks from the rendering framework and makes it easier to add new tasks. Later, project-wise pyramid building has also been improved, leading to an 80% reduction in render time. While I do not recommend making Python files other than main.py callable, I believe it is acceptable to modify main.py to accept arguments that enable it to execute a single task, as it currently does.

[cyberbobjr]

Another tips for MacOS : The name of the "arial.ttf" font should be variabilized.

[cff29546]

Another tips for MacOS : The name of the "arial.ttf" font should be variabilized.

Just updated the codebase to support configurable font