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 - Han
1
« on: March 03, 2017, 10:29:18 am »
Never played minecraft (I know what it is, my nephew loves it) but when you blit sprites, you can use polyfill afterward and shade it with alpha blending. So for example, blit your sprite (presumably a square image), then create a square using polyfil and fill it with a color (black) and modify the alpha channel so that it is opaque or clear, or anywhere in between.
2
« on: November 13, 2014, 10:16:22 am »
I dont get it Tim. If the splash screen is required for initialisation, why can the numbers be typed in (and remembered)whilst the logo is there?.
On one hand, we say the calculator is "booting up" or "initialising" and thus nothing can be seen except for the logo. Yet, we can type in immediately the calculator is turned on AND it has this fortunate ability to remember what has been typed in whilst the logo is still being displayed. Thus...leading me to conclude that the logo can be replaced with the proper calculator screen.
There must be a way that the logo display time (or bootup time) can be adjusted from the current 1.4seconds to say 0.3seconds...after all, the calculator has an inbuilt abilty to remember immediatly whats been typed in..its just been designed not to display it for 1.4 seconds.
Regards
That simply suggests that the calculator already initialized the keyboard and input buffer. That doesn't mean that everything else is properly initialized. So while you can enter stuff in, it doesn't mean that the calculator is necessarily ready to do anything -- including displaying the home/cas screen.
3
« on: September 18, 2014, 03:30:21 pm »
5
« on: September 15, 2014, 06:46:31 pm »
Graph3D has been updated to work with the latest firmware (6030). If you updated to the most recent firmware, then the older versions no longer work due to updates to the TRIANGLE command. Version 2.2polytrace still works, but uses a very slow rendering routine. Version 2.3 (the latest) now combines all the features of the previous versions into a single app.
6
« on: May 02, 2014, 08:35:32 am »
Regarding the high score being reset, there is a way to do this but you will have to access the variable indirectly.
init_highscore()
begin
local temp="_tetrisHS:={{"Player1" 12345},{"Player2",234}};"; // make sure that you initialize properly; change list to whatever you use
CAS(temp); // evaluates string inside temp as if done from CAS command line; creates _tetrisHS variable
end;
// get the n-th high score
get_highscore(n)
begin
local temp="_tetrisHS(" + n ")";
iferr
local score=CAS(temp);
then
init_highscore(); // make sure this runs properly or you end up with an infinite loop
get_highscore(n);
end;
return(score); // return a list consisting of something like {"PlayerName" 1234}
end;
You can create a similar procedure for storing high scores. Indirection will not require you to have the variable initialized within your source code. Thus when you edit the source, the variable _tetrisHS will remain intact.
7
« on: January 19, 2014, 11:37:59 pm »
Not even close -- Ghost n Goblins was ridiculously hard in my opinion. I can easily 1-life Life Force even having not played in over 10 years.
8
« on: January 19, 2014, 02:37:30 pm »
I know collision can be a very delicate part of game dev, and a poorly coded routine can ruin a very good game otherwise. I asked not because I doubt of your skills but because I don't know yet how to handle that on the Prime myself. I don't need it for Trailblazer (which is really almost finished, I coded track editor on-calc in the train, that was an... interesting experience. ^^ ), but I will definitely need some for my next project. There are so much known way to handle collision but each platform has its own strength and weakness. Well I hope it will work for you and I really look forward to play your game. Will you release a demo soon ?
Indeed collision detection is what I dread implementing the most because I always wonder if my initial ideas will be fast enough (and more often than not, they are not fast enough). Speed is not only a result of good ideas, but also of good data formats. Unfortunately, I tend to figure things out by trial and error rather than spend a lot of time planning out the code. As for a demo, I will probably release one after I at least implement one enemy type and make it destructible. In terms of ease, a simple enemy type would result in a faster release of a demo, but I think I may go the longer route and program a mini-boss for a demo.
9
« on: January 18, 2014, 07:21:49 pm »
Parallax scrolling would not be difficult to add. It would require scrolling two or more different backgrounds at different rates. I have not decided whether this will be a port of Life Force, if it will just use the mechanics from the series. So parallax scrolling could certainly be an option.
10
« on: January 18, 2014, 11:36:10 am »
11
« on: January 18, 2014, 10:41:39 am »
That looks very nice. Do you have any idea how you will implement collisions detection yet ?
Some ideas I had were to use pixel tests. The game screen is broken into layers. There will be a layer for background walls, and a layer for enemies. "Blank" regions in each layer are colored with a masking color (lime green). The collision detection will first detect if the position of a shot corresponds to a lime green pixel (no collision) in the wall / enemy layers or a non-green pixel (collision occurred). If enemy collision occurs then it will search the enemies list and mark it as destroyed. For speed, only the ship and the bullets will detect collision. For the ship, we search a bullet list only if the colored pixel is within a specific range of colors (thatwill not be used for enemies). The thought is that a pixel test would be quick and save some computational time. The alternative would be to search the enemy list and possibly get no collision, which eats up CPU time. My approach right now is to add a few elements of the game in at a time and find the slowest frame rate. If it is acceptable, then I'll complete the project and turn it into an actual game in which all the other frames are timed accordingly so that there aren't moments where everything moves fast and other areas where you see too much slowdown. In the event that I cannot optimize the code to an acceptable frame rate, I'll just release the code as is for someone else to play with. Maybe I should have made a blog on the process...
12
« on: January 17, 2014, 09:48:42 pm »
The general idea is to do something like: BLIT_P(G0,G1,x,0,320+x,240); where G1 is much wider than 320 pixels. The extra area is buffered with new columns of background (32 pixels wide). Lastly, x is incremented as x:=(x+1) MOD 32. Everything is shifted for the next column of background data and repeats.
13
« on: January 17, 2014, 03:47:49 pm »
Progress: Implemented ship motion, shooting, and dynamic backgrounds. The background is generated as needed. The user may shoot while moving the ship. The firing rate is dependent on whether the shoot button is held down or pressed rapidly (to mimic the old NES behavior). Any "stuttering" happening with shooting and moving is due to my inability to use the left hand and simultaneously shoot and move, while filming with my right hand. On the calculator, it's very smooth. The entire source code is 13KB including graphics (so far). I imagine the game engine will (hopefully) be under 100KB and the rest will be graphics. I wrote a playable version of COLUMNS that was only 35KB or so; I cannot imagine this would be that much more complicated.
14
« on: January 15, 2014, 10:15:17 pm »
Actually, couldn't you just do
mainprogram()
begin
makemat(
// code that loops x from 1 to 25 and y from 1 to 25 goes here
return(0);
,25,25);
end;
if the code was short enough?
Not really. They only way it could be short enough is if it were a single "command" (i.e. built-in command or procedural function created either in the same source file or made available via export). If your code requires more than a single semicolon, then I am pretty sure it won't work (though I never tried myself) because the arguments of makelist or makemat must be comma-separated.
15
« on: January 15, 2014, 08:19:16 pm »
The last function has one too many "END;"s and the ICON command must not be declared inside any procedure (much like EXPORT).
|
Show Posts