This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 127 128 [129] 130 131 ... 153
1921
« on: October 08, 2010, 10:18:37 pm »
are you still going to implement both? or which ever one wins? it's really close though, it'll probably end up being your choice. 
I've already implemented both, the user could choose which one looks best on a sprite-by-sprite basis.
...and the default choice? 
I have no idea lol
1922
« on: October 08, 2010, 09:32:57 pm »
You have no idea how long this took  If you squint a bit, it looks like the real thing! EDIT: See this post for my vastly improved second attempt.
1923
« on: October 08, 2010, 06:51:23 pm »
1924
« on: October 08, 2010, 05:56:19 pm »
Would be nice if someone could tell me how to include @ and % as Text( outputted String. If I use the characters in my code, they will be converted to other characters.
It doesn't look like anybody answered this yet, so I will. You can insert normally inaccessible characters (or any characters) by just inserting the ASCII hex data for that character at that position (you can find the hex values here). @ would be [40] and % would be [25]. When combining hex data with strings, though, you have to make sure that strings of normal characters are enclosed in quotes and hex data is not. For instance, to display the string "100% Complete" with the Text() function, you would do this: Text(X,Y,"100"[25]" Complete")
1925
« on: October 08, 2010, 04:11:07 am »
I was thinking something like this and get the best of all worlds
Of course this might be a bit big, but i think the animating transparency is the way to go. You could have a flashing light grey maybe, or a rolling light grey by pixel for example
Something like that would be nice for editing the individual sprite, but it would be difficult to implement in the filesystem. Unless you have some ideas about how to make it easy and not interfere with other things on the screen.
1926
« on: October 08, 2010, 02:06:19 am »
Why not just have white be transparent? Then light gray would be white, dark gray would be gray, and black would be black.
Why not just have white be transparent? Because then light gray would be white, lol 
1927
« on: October 07, 2010, 11:50:50 pm »
Ah ok. What does change location accross OS versions? Mapar007 told me about the Garbage Collecting routines.
Mostly just added stuff, but undocumented features might get removed (I'm not sure, though).
EDIT: The poll seems nearly unanimous now
Well, Mapar told me the GC routine got moved from a location to another accross OS versions and it's not a new feature.
The garbage collect routine very well may have moved. But seeing as there isn't actually a garbage collect bcall and garbage collecting is handled entirely by the OS, unless you have a hacked OS with different parts from different versions, garbage collecting should work fine.
1928
« on: October 07, 2010, 11:44:24 pm »
EDIT:
Also, the line routine is not hijackable, so it would have to be an entirely different routine for the back buffer or a more inefficient routine for arbitrary buffers. Same thing with the circle command.
I'd be ok with a whole second copy of the Line() routine being needed for the back buffer, or a more inefficient one for arbitrary buffers. I'm not terribly worried about speed, it would just be nice to have these for UI drawing.
1929
« on: October 07, 2010, 11:36:35 pm »
The Ans variable should be accessible already with "Ans"->Str1 just like you read other OS variables.
GetCalc("Ans") returns 0 for me whether I use the Ans token or spell it out. Also, I believe storing strings to Ans involves a more complex method in which you need to create a temporary string variable in which to store the string, and then store that variable's name in Ans. There is no bcall for making menus as far as I am aware.
Is this not it?
1930
« on: October 07, 2010, 11:23:43 pm »
Explorer and Calender, with an Exit option coming soon
I didn't go for anything fancy or obscure because coding hex/text sprites manually is a bloody pain.
If you wait maybe a month or so, I'll be releasing the most epic on-calc sprite editor the world has ever seen
1931
« on: October 07, 2010, 09:23:16 pm »
6-7, damn, this is making it hard to decide  I think I'll probably just add support for both display modes and let the user choose which mode they want to use on a sprite-by-sprite basis. However, it would be nice if were the vote were leaning a bit one way so I can at least choose a default display mode.
1932
« on: October 07, 2010, 09:19:29 pm »
I have a list of feature requests here. Don't feel like you need to include all, most, or even any of these, as I and others can get by without them, but they would be nice. I'll list them in descending order of a combination of how much I would want to see them added and the probable ease of implementation: - InsertMem and DelMem bcalls. They would be invaluable for editing variables with a large amount of data in them. (If anything, this is the feature I would want the most, and it seems fairly easy to implement)
- Case statements.
- Reading from/storing to the Ans variable for things other than integers (namely strings).
- Dialog (menu) bcalls.
- General bcall support.
EDIT: Wow, how did I miss this: the Line() command working on back/arbitrary buffers. The routine's already there, it's gotta only take like 10 seconds to modify it for this. I hear you already did it for the pixel commands, which is good.
1933
« on: October 07, 2010, 03:01:09 pm »
The problem is that sprite data isn't stored in succession in picture variables. Picture variables store data line by line, with each line being 12 bytes. Each byte of an 8x8 sprite is on a different line, so there's a separation of 11 bytes between each byte of the sprite (as opposed to 0, which is what you want for sprite routines like Pt-Off). Say your sprite was just a filled square. It's data would be [FFFFFFFFFFFFFFFF]. But when displayed in a picture variable, the data would look like this: | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | FF | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 | 00 |
... 64 rows This gives 11 bytes of non-sprite data on each row, resulting in 11 bytes of space between each byte in the sprite.
1934
« on: October 07, 2010, 12:11:01 pm »
It's 65.5KB, or 64KiB
1935
« on: October 07, 2010, 01:57:57 am »
Yeah, I did an overworld tileset, although I'm not terribly good at spriting. It's recognizable, but I think any tiles you made would probably look better anyways.
Pages: 1 ... 127 128 [129] 130 131 ... 153
|
Show Posts
, although if someone really said that in a political context it might sound a bit racist 