Conversation
|
Made a couple more changes, notably removed the import cache folder from git tracking and updated the signal connections and the likes + corrected errors in the revealer script. |
|
One small note on something I just noticed: In the UI practice scene, there's a CodeHighlighter resource embedded. I think it's a resource we would want to share across all code editors across the application, but I couldn't find where it is in the scene to extract it as a reusable resource. |
|
I did extract a re-usable TRES, but I must have missed that one. I'll see about tracking it down. |
|
I'll throw in a little extra feature, could you add resolution support? In particular, not locking to 1080p and allowing up to 4k resolution, possibly with a dropdown menu in the settings? I'm throwing this in now and it could be part of this PR because if we're going to test the app and review the visuals, we might as well do it at high resolution so we can catch any icons or resources that need to be tweaked to look crisp. |
|
09. Smooth scrolling is a bit jittery on Firefox (Linux) This is a bit hard to describe, so I made you a video clip to show you how it works on my end. It's only happening with Firefox. I've reduced the scroll sensitivity to the minimum here and when I'm slowly turning the wheel, the motion is somewhat smooth (and slow according to the scroll sensitivity setting), but if I start turning the wheel faster, the bar makes sudden jumps. I remember then that back in the day, I had problems with excessive events being emitted input-wise very differently between browsers and the desktop. I don't know if that might be the case, but probably the scroll algorithm could use some tweaks to normalize the flow of input events. Also with touchpads, the input events tend to be every single frame. And work differently from the mouse wheel.as users would probably want to control the scrolling a bit more, but we don't really support that. Video_2026-03-25_21-38-05.mp4Now, for this issue specifically, this can be briefly investigated and then offloaded to a new issue to address later. Or a quick fix can be implemented for the firefox hiccups now and an issue opened for reworking smooth scrolling. |
|
Just tracking these:
|
|
After some testing, I've figured out that there's a bug with web export apps where the Current workaround has to be to disable low CPU mode until that's fixed, which does mean losing access to FPS limits on web, as currently |
|
Firefox seems to provide scrolling factors that are half the size to Chrome's, but possibly more often. I've made it use InputEvent's factor to calculate a change delta. It seems to normalize the movement between them. |
|
If you happen to be developing on Windows, could you test the Windows magnifier (accessibility option) on the desktop export? It was incompatible with godot 3 but if it works with 4 we can mark this PR as closing #1213 |
|
I switched to Fedora a couple months ago, but I still have my windows 11 boot on hand. However, I had no issues with magnifier zooming in with the app in full screen on either of the godot 3 or 4 ports of the app. |
|
Going to defer the resolution stuff for now. I did a couple tweaks to the core page to make it a bit more resize friendly on ultra wide (in that things will stay centred when full screen). I did spend a few hours toying with it and I found that:
|
|
Pending additional testing and feedback, gonna green light the PR since it otherwise functions A to Z pretty well. |
|
Thank you very much! Overall it's looking pretty good. This will be the last round for me, and after that I will have two testers go through the entire application and make a report. A few more after some more testing:
For the first item, expected:
Current:
For the course index, example:
|
|
Nevermind. In the godot 3 app the credit label isn't affected by font changes, so that's likely what's happening. I've replicated this behaviour here. |
|
The profile was saving multiple times. Not sure why it wasn't noticeable in the godot 3 version as it happened there too. Fixed it by queueing the save so that even if save() is called multiple times, it only happens once. There's still a bit of a spike but it's a lot less egregious. Not sure if there's been a change with ResourceSaver between godot 3 and 4 that made it a bit slower. Alternatively would be to save/load with var_to_string and save one line at a time behind await process_frame, or to compile with threads support and save behind a thread. |
|
Thanks. I did a bit of testing and profiling because the lag remained long for me and saving multiple times itself should not have been too slow, although it's good that this has been cleaned up. I found that the root issue was when we change the fonts in the theme, it caused lots of notifications and re-layouts. But excessively. In the profiler, strangely enough, the time spike was reported as physics time. I managed to reduce it from 4000 ms to 500 ms by removing many references to theme resources. That's still quite long. I think this could be improved by producing fewer individual controls, notably lesson content blocks. Hopefully at least. The app could generally use a pass later on to simplify or consolidate the UI and theme etc., but maybe I will put Yuri on that when he is available (former Godot UI and theme system maintainer). I'll do a bit more testing before pushing. I'm also adding some logic so if you change settings that are not related to theme resources it doesn't touch the theme and doesn't cause any re-layout so the change is perceptually instant. |
| const LESSONS := { | ||
| "res://course/lesson-1-what-code-is-like/lesson.bbcode": "lesson-1-what-code-is-like/lesson.bbcode", | ||
| "res://course/lesson-2-your-first-error/lesson.bbcode": "lesson-2-your-first-error/lesson.bbcode", | ||
| "res://course/lesson-3-standing-on-shoulders-of-giants/lesson.bbcode": "lesson-3-standing-on-shoulders-of-giants/lesson.bbcode", | ||
| "res://course/lesson-4-drawing-a-rectangle/lesson.bbcode": "lesson-4-drawing-a-rectangle/lesson.bbcode", | ||
| "res://course/lesson-5-your-first-function/lesson.bbcode": "lesson-5-your-first-function/lesson.bbcode", | ||
| "res://course/lesson-6-multiple-function-parameters/lesson.bbcode": "lesson-6-multiple-function-parameters/lesson.bbcode", | ||
| "res://course/lesson-7-member-variables/lesson.bbcode": "lesson-7-member-variables/lesson.bbcode", | ||
| "res://course/lesson-8-defining-variables/lesson.bbcode": "lesson-8-defining-variables/lesson.bbcode", | ||
| "res://course/lesson-9-adding-and-subtracting/lesson.bbcode": "lesson-9-adding-and-subtracting/lesson.bbcode", | ||
| "res://course/lesson-10-the-game-loop/lesson.bbcode": "lesson-10-the-game-loop/lesson.bbcode", | ||
| "res://course/lesson-11-time-delta/lesson.bbcode": "lesson-11-time-delta/lesson.bbcode", | ||
| "res://course/lesson-12-using-variables/lesson.bbcode": "lesson-12-using-variables/lesson.bbcode", | ||
| "res://course/lesson-13-conditions/lesson.bbcode": "lesson-13-conditions/lesson.bbcode", | ||
| "res://course/lesson-14-multiplying/lesson.bbcode": "lesson-14-multiplying/lesson.bbcode", | ||
| "res://course/lesson-16-2d-vectors/lesson.bbcode": "lesson-16-2d-vectors/lesson.bbcode", | ||
| "res://course/lesson-17-while-loops/lesson.bbcode": "lesson-17-while-loops/lesson.bbcode", | ||
| "res://course/lesson-18-for-loops/lesson.bbcode": "lesson-18-for-loops/lesson.bbcode", | ||
| "res://course/lesson-19-creating-arrays/lesson.bbcode": "lesson-19-creating-arrays/lesson.bbcode", | ||
| "res://course/lesson-20-looping-over-arrays/lesson.bbcode": "lesson-20-looping-over-arrays/lesson.bbcode", | ||
| "res://course/lesson-21-strings/lesson.bbcode": "lesson-21-strings/lesson.bbcode", | ||
| "res://course/lesson-22-functions-return-values/lesson.bbcode": "lesson-22-functions-return-values/lesson.bbcode", | ||
| "res://course/lesson-23-append-to-arrays/lesson.bbcode": "lesson-23-append-to-arrays/lesson.bbcode", | ||
| "res://course/lesson-24-access-array-indices/lesson.bbcode": "lesson-24-access-array-indices/lesson.bbcode", | ||
| "res://course/lesson-25-creating-dictionaries/lesson.bbcode": "lesson-25-creating-dictionaries/lesson.bbcode", | ||
| "res://course/lesson-26-looping-over-dictionaries/lesson.bbcode": "lesson-26-looping-over-dictionaries/lesson.bbcode", | ||
| "res://course/lesson-27-value-types/lesson.bbcode": "lesson-27-value-types/lesson.bbcode", | ||
| "res://course/lesson-28-specifying-types/lesson.bbcode": "lesson-28-specifying-types/lesson.bbcode", | ||
| } |
There was a problem hiding this comment.
Here I'd say remove the lesson.bbcode, and also the lesson number: for example, the slug for res://course/lesson-8-defining-variables/lesson.bbcode would be just defining-variables: this way slugs don't change or depend on lesson numbers and we address this issue: #911
Moving forward we'll likely change, insert, or append lessons, so having l;esson numbers in slugs would be "invalidated" again.
To decide: doing something similar for practices? E.g. having cannonical urls like: $lessonSlug/$practiceSlug?
Because there again practice numbers may change, but unique slugs wouldn't. The main reason I'm putting this as a question is that the natural place to write slugs would be in the bbcode meaning to get the TOC we would need to parse all bbcode at startup.
|
By the way, at any point we can merge this work, for example, perhaps after finishing the URL slugs, so it ends up in main, and open issues and address and merge changes gradually (or directly commit changes to main), whichever is more comfortable for you. Just let me know if you'd like to merge and work in main vs keep working in this branch |
The errors were hidden by Godot by turning signal names into Callable. But actually, some of these things are signals now and not methods anymore. In Godot 3, there were signals and methods with the exact same names sometimes.
…re a layout update
…ce IDs to kebab case
67d8418 to
339f030
Compare
|
Okay, I think at this point the app, with the new simplified slugs, is in a working condition well enough to get merged. Next week I can start tackling outstanding bugs, newly opened tickets, and optimization. But it should be good to go to main now. |











Converts the whole of the app from the 3.6.2 custom build with GDScriptParserWrapper to a 4.6.2 custom build with a GDScriptErrorChecker. Both are uploaded to the Razoric480/custom-godot-builder repository.
Fixes #1187. Fixes #1259. Fixes #911. Fixes #1262.
Current State
Integration tests pass
Integration Test Log
Integration Test resultsPotential issues
Some internals to keep in mind
run()(no coroutines or stepping) or arun_coroutine(CoroutineController).yield()is replaced withawait coroutine_controller.step_requested, and run_coroutine() should end with ancoroutine_controller.finished.emit().Conversion gotchas I ran into
map_to_local()is centered, whereas TileMap'smap_to_world()was top left cornerright()function gave you the characters to the right of the index. godot 4'sright()gives you X characters from the right side (which, to be fair, matches whatleft()does).super._ready()and the like are no longer implicit and need to be called explicitly. I think I've found most of them but it's possible I've missed some.Additional improvements and changes
Some are just general improvements, others were requested changes to app functionality.