tifreak8x wrote:
Apps probably won't happen, since DCS is an app as well, it would make memory management, and returning to Doors, a bit of a mess, from what I understand of that previous request.
This is correct; unfortunately, it becomes rather messy to safely regain control after another App has run. I would love to have Doors CSE be able to run Apps, considering how often the feature is requested, but it just doesn't seem feasible at this point without making compromises. As far as hiding the Archived/Hidden/Locked icons, do you really find they add that much clutter? I feel like the extra information they provide makes the small about of space they take worthwhile.
You have informed me that you've got the ability to launch other applications under control, and that the problem was regaining control when they exit. I may have a solution: install an app change hook.
The easy case is if the hook is triggered when the appRunning flag at (iy+apiFlg) is unset, in which case you know the application has just exited and can resume control yourself, probably with some care taken in handling.
The harder case is if the hook is triggered with a=2, in which case the user attempted to shut down the calculator from within an OS context launched by the application. I presume it's harder not only because you ideally have to still allow the power down to go through and resume control on turning back on, but also because I'm not sure how properly the application is cleaned up at that point. As far as I can tell, the appRunning flag hasn't gotten unset at that point (and it seems it never does... bug?), so it's possible that other application teardown things haven't executed as well.
One thing that might be nice is to have a Mimas-type scrollbar in the Basic editor. I don't know about anyone else, but I find it kind of annoying when I am scrolling through some of those endless programs and don't know about where I am.
Another thing would be adding a feature to autounhide programs, like the current unarchive feature in the header. That way the program menu can be cleaner and the programs can still be run.
And putting the link feature back in Doors would be kind of nice, particularly if it was a windows where you could decide the file name, archive status, set it to be hidden, ect. Or could you do that with a separate program?
OK I was thinking about the 16x16 sized sprite routine requests and such and I think I have an idea that can satisfy it.
Basically how DrawSprite for sizes > 8x8 works is you need to specify a list of the 8x8 chunks that make up your sprite. So for a 16x16 sprite you need to manually specify each chunk: 1,2,3,4. For a 32x32 sprite you need to specify 16 chunks! Having more arguments can cause the parser to slow which is bad. I could have a variant routine that just takes the 1st index in your sprite data and assumes that the sprite chunks that make up the larger sprite follow it sequentially. That would have a low impact on code size and should provide the needed functionality.
Thoughts?
I think it would be nicer if it just assumed for you. If you specify 5 as the 16x16 sprite, it should assume it's chunks:
5|13
6|14
and 32x32:
5|13|21
6|14|22
7|15|23
That way we don't need to add extra arguments. The limit to the user is then that the sprite sheet needs to be laid out like that, but I imagine that'll be how most everyone would want to do it anyway.
Yeah i was going to just have it so that you specify them sequentially in order, which makes the code easier (lol) but the appvar creation a little more involved, but still not too difficult. Either way the idea should help.
I was also thinking about a bounding box collision routine that can be used for sprites? Something like:
real(4,7,X0,Y0,WIDTH0,HEIGHT0,X1,Y1,WIDTH1,HEIGHT1
And returns 0 or 1 in Ans depending on if the coordinates overlap.
While we're discussing sprite routines, I've never understood what the XOFFSET and YOFFSET arguments for
DrawSprite are; they just end up as 0 in all my programs. I heartily second Merth's opinion about assuming that a large sprite will be laid out the same way on-screen as in the spritesheet unless otherwise specified.
The XYOFFSET arguments are just used to offset the sprite from it initial location. It can be used when you have world coordinates->screen coordinates or for animations (maybe jumping but still want to collide with the 'ground' position).
Its just that the max sprite size would be 64 pixels, would this be an issue?
What would be nice is if Celtic2CSE line copy allowed reading programs and appvars up to 65535 bytes large. Right now, past 7 KB or so it fails to store the line of code to Str9.
Also it would be nice if the wiki had any documentation on how to copy or read a line of code from an actual appvar instead of a program.
tr1p1ea wrote:
Yeah i was going to just have it so that you specify them sequentially in order, which makes the code easier (0x5) but the appvar creation a little more involved, but still not too difficult. Either way the idea should help.
I'm not sure I understand. AppVars shouldn't be any different. Store it all exactly how you store it now, but just have to code extrapolate the correct tiles.
By store i mean which 8x8 blocks equate to what ie; rearrange the 8x8 blocks in the appvar into sequential order.
If you want it to look the same way in the appvar as it does on screen - then there is code overhead (slower).
Will people need sprites larger than 64 pixels? (maybe 128?). What happens when you have large sprites that dont all fit into a 128x64 sized appvar nicely?
Another idea i had was to include a facility for fullscreen images at a larger resolution than 80x60(scaled). I was thinking 160x120 32 colour images - this would take up 12k for a single uncompressed image.
Ive added some code based on an idea by DJ, it enables you to set a COLOUROFFSET that is added to each pixel as they are drawn. It works for sprites and for a new filled rectangle routine. The effect is that you can cycle through the colours of an image like so:
Here is another image demonstrating the sprite routine (notice only the sprite changes. Note that transparency is still preserved.
Ive added support for 32 colour 160x120 images (scaled to fullscreen). These images are 12000bytes for image data + 32 bytes for the palette.
The 32 colours are not predefined and can be made up from a selection of the 256 colour xLIBC palette.
Example images:
Looks pretty sweet oncalc and offers more flexibility than the 80x60 bg images without taking up too much size*.
Very nice, tr1p! Those are indeed extremely impressive images being displayed
I notice one of those images is a Pokemon Purple map
That is so awesome! (Now, time for a who's that Pokemon game!)
Hehe yeah, well you need to ask tifreak about that
.
The images are just quick tests, but you can do a bit with 32 xLIBC colours by the looks of it.
Great, I look forward to merging code with you to get these new features into the Doors CSE 8.1 codebase. How much space do they add?
The colour rotating is only a few bytes, but the 32 colour image routine is sizeable. I will be going through and optimising some routines for size to reduce the footprint. Still testing at this stage but will have through to you soon.
Merthsoft:
The image format is:
[32bytes palette data (made up out of xLIBC colours so 1-byte per colour]
[12000bytes 160x120 pixels data where each byte is a palette index 0-31]
Note that the images are stored by 'column' from top down ... and to make things interesting each index is 5-bits and they are packed into each byte. So the first 8-pixels will look like this:
00000111 11222223 33334444 45555566 66677777
Hence 12000 = 160x120x5/8
Hopefully this makes sense?
I had an idea for the tile maps. It would be cool if you could specify a scale for drawing the sprites. So, like, in the AppVar, they're 8x8 sprites, but when you draw it, it scales it up to 16x16.
Would that look a little funny with the pixels being so big?
I could look at the possibility of scaling, but an issue for tilemaps would be that 120 is not wholly divisible by 16. So you would be stuck with half a tile and would require some special-case code (trying to keep code footprint to a minimum).
On top of that i went against the grain and implemented a DRAWSPRITE alternative that takes the starting index for a sprite of any size and assumes that the rest of the sprite follows that number sequentially. The reason is so that appvar space can be maximized and for ease/speed of code. The good thing is say you have a 16x16 sprite with 2 frames, you can still specify the offset to your index list (by setting PICINDEXSTART) to achieve this. But since you only need the first index, it saves a lot of space in code:
real(4,7,X,Y,WIDTH,HEIGHT,XOFFSET,YOFFSET,TRANSINDEX,UPDATELCD,PICINDEXSTART,INDEXFRMAE0,INDEXFRAME1...etc
One other function that i will include is DRAWSPRITECHECKCOLLISION which will return 0/1 depending on if 2 sets of bounding-box coordinates overlap. It can be used with sprite<->sprite collision detection etc.
tr1p1ea wrote:
Would that look a little funny with the pixels being so big?
I don't think it's look too funny. They'd just look bigger.
Quote:
I could look at the possibility of scaling, but an issue for tilemaps would be that 120 is not wholly divisible by 16. So you would be stuck with half a tile and would require some special-case code (trying to keep code footprint to a minimum).
I guess just leave that column empty and let the user draw whatever he wants? I'm not sure the best way to handle that.
Quote:
On top of that i went against the grain and implemented a DRAWSPRITE alternative that takes the starting index for a sprite of any size and assumes that the rest of the sprite follows that number sequentially.
I like this.
I also wanted to check on some of my other suggestions from before. Namely transparency in the tilemaps and custom fonts. Also this: GetKeyArrowsCheckTile report what tile you collided with anywhere? If not, it would be useful if this was stored in Ans or something. Also which key was pressed?