Posted: Thu Dec 15, 2005 5:30 pm Post subject: Review: Ready to Program
Intro
I actually found RTP on my school computers today, and I thought I would do a fairly objective review. Can't do any harm, right? Granted, it only takes the face view of it since I have obviously only 'used' it for an hour, so others will definately know better than me.
Disadvantages
-It uses the outdated Java 1.4.2 sdk, not sure if this is exclusive for the version I was using, but it seems unlikely the program will be updated by holtsoft and by every school in time with Java updates.
-Uses the IBM Java compiler, why? Java should be Java.
-HSA.* classes, not just the HSA.console class. They teach you to do things the wrong way. For more examples, do a search for HSA console on compsci.
-Promotes a "write code for you" attitude, by creating the outline of various kinds of program for you. This is minor, as it is very limited.
-Writes extraneous comments in the above mentioned outlines, which promote the user to continue doing the same.
-For an IDE, lacks features.
-Has strange requirements to create a runnable program.
Advantages
-Auto-intentation
-Help is fairly easy to use, especially if you are a previous Turing user, though really no difference to the same at java.sun.com
-First thing to show me a simple application framework.
-Fixed the bug in the Turing editor outlined here.
-Simple layout with syntax highlighting, but any good editor would also have this.
I would point out that any of the advantages mentioned can be found elsewhere.
Conclusion
I find Hikaru's post to be true:
Quote:
For most basic classroom uses, Ready is okay. Remember, just because you're using RTP does NOT mean you'll neccesarily have to use the HSA Console classes or any of that crap. I would definitely stay away from using that, but there's nothing wrong with using Ready at first -- it is nothing more than a syntax-highlighting text editor with compile+run bound to its F1 key. Yes, it does use a different compiler, but by the time students get to the point where that makes any difference, it will be trivial to switch them over to Sun JDK.
found here for reference on the discussion and points made by others.
Thoughts? Comments? I will add any fair additions/changes to the list.
*edit* Don't know if anyone will ever read this, but after more experience with various Java environments, I would compare Java with RTP to "Java" with J# or J++. That's not a good thing, by the way.
Sponsor Sponsor
jamonathin
Posted: Wed Dec 21, 2005 2:51 pm Post subject: (No subject)
I don't really know much about outdated java versions, but what i do know is that when running the code below, it has a fatal error, but it's not your fault!!!11. But it's not like it hasn't worked before on Ready to Program. I have run this code before, only it works, sometimes, not shure when that is tho. I do know that this code works 100% of the time on Eclipse, but like I said, I dont know much about java and whatnot so, yeah.
Java:
//********************************************************************// //* F. PERMADI MAKES NO REPRESENTATIONS OR WARRANTIES ABOUT THE *// //* SUITABILITY OF *// //* THE SOFTWARE, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT *// //* LIMITED *// //* TO THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A *// //* PARTICULAR PURPOSE *// //********************************************************************// import java.awt.*; import java.applet.*;
//*******************************************************************// //* main class //*******************************************************************// publicclass game extendsAppletimplementsRunnable { // this is Java's stuff Thread fThread;
// player's attributes int fPlayerX = 100;
int fPlayerY = 160;
int fPlayerArc = ANGLE0;
int fPlayerDistanceToTheProjectionPlane = 277;
int fPlayerHeight =32;
int fPlayerSpeed = 16;
int fProjectionPlaneYCenter = PROJECTIONPLANEHEIGHT/2;
// the following variables are used to keep the player coordinate in the overhead map int fPlayerMapX, fPlayerMapY, fMinimapWidth;
// movement flag boolean fKeyUp=false;
boolean fKeyDown=false;
boolean fKeyLeft=false;
boolean fKeyRight=false;
//*******************************************************************// //* Create tigonometric values to make the program runs faster. //*******************************************************************// publicvoid createTables() { int i;
float radian;
fSinTable = new float[ANGLE360+1];
fISinTable = new float[ANGLE360+1];
fCosTable = new float[ANGLE360+1];
fICosTable = new float[ANGLE360+1];
fTanTable = new float[ANGLE360+1];
fITanTable = new float[ANGLE360+1];
fFishTable = new float[ANGLE60+1];
fXStepTable = new float[ANGLE360+1];
fYStepTable = new float[ANGLE360+1];
for(i=0; i<=ANGLE360;i++) { // get the radian value (the last addition is to avoid division by 0, try removing // that and you'll see a hole in the wall when a ray is at 0, 90, 180, or 270 degree)
radian = arcToRad(i) + (float)(0.0001);
fSinTable[i]=(float)Math.sin(radian);
fISinTable[i]=(1.0F/(fSinTable[i]));
fCosTable[i]=(float)Math.cos(radian);
fICosTable[i]=(1.0F/(fCosTable[i]));
fTanTable[i]=(float)Math.tan(radian);
fITanTable[i]=(1.0F/fTanTable[i]);
// you can see that the distance between xi is the same // if we know the angle // _____|_/next xi______________ // | // ____/|next xi_________ slope = tan = height / dist between xi's // / | // __/__|_________ dist between xi = height/tan where height=tile size // old xi| // distance between xi = x_step[view_angle]; // // // facine left // facing left if(i>=ANGLE90 && i<ANGLE270) {
fXStepTable[i] = (float)(TILE_SIZE/fTanTable[i]);
if(fXStepTable[i]>0)
fXStepTable[i]=-fXStepTable[i];
} // facing right else {
fXStepTable[i] = (float)(TILE_SIZE/fTanTable[i]);
if(fXStepTable[i]<0)
fXStepTable[i]=-fXStepTable[i];
}
for(i=-ANGLE30; i<=ANGLE30; i++) {
radian = arcToRad(i);
// we don't have negative angle, so make it start at 0 // this will give range 0 to 320
fFishTable[i+ANGLE30] = (float)(1.0F/Math.cos(radian));
}
//*******************************************************************// //* Called when program starts //*******************************************************************// publicvoid start() {
createTables();
fThread=newThread(this);
fThread.start();
}
//*******************************************************************// //* Draw ray on the overhead map (for illustartion purpose) //* This is not part of the ray-casting process //*******************************************************************// publicvoid drawRayOnOverheadMap(float x, float y) {
fOffscreenGraphics.setColor(Color.yellow);
// draw line from the player position to the position where the ray // intersect with wall
fOffscreenGraphics.drawLine(fPlayerMapX, fPlayerMapY,
(int)(PROJECTIONPLANEWIDTH+((float)(x*fMinimapWidth)/(float)TILE_SIZE)),
(int)(((float)(y*fMinimapWidth)/(float)TILE_SIZE)));
// draw a red line indication the player's direction
fOffscreenGraphics.setColor(Color.red);
fOffscreenGraphics.drawLine(fPlayerMapX, fPlayerMapY,
(int)(fPlayerMapX+fCosTable[fPlayerArc]*10),
(int)(fPlayerMapY+fSinTable[fPlayerArc]*10));
}
int verticalGrid; // horizotal or vertical coordinate of intersection int horizontalGrid; // theoritically, this will be multiple of TILE_SIZE // , but some trick did here might cause // the values off by 1 int distToNextVerticalGrid; // how far to the next bound (this is multiple of int distToNextHorizontalGrid; // tile size)
float xIntersection; // x and y intersections
float yIntersection;
float distToNextXIntersection;
float distToNextYIntersection;
int xGridIndex; // the current cell that the ray is in int yGridIndex;
float distToVerticalGridBeingHit; // the distance of the x and y ray intersections from
float distToHorizontalGridBeingHit; // the viewpoint
int castArc, castColumn;
castArc = fPlayerArc;
// field of view is 60 degree with the point of view (player's direction in the middle) // 30 30 // ^ // \ | / // \|/ // v // we will trace the rays starting from the leftmost ray
castArc-=ANGLE30;
// wrap around if necessary if(castArc < 0) {
castArc=ANGLE360 + castArc;
}
for(castColumn=0; castColumn<PROJECTIONPLANEWIDTH; castColumn+=5) { // ray is between 0 to 180 degree (1st and 2nd quadrant) // ray is facing down if(castArc > ANGLE0 && castArc < ANGLE180) { // truncuate then add to get the coordinate of the FIRST grid (horizontal // wall) that is in front of the player (this is in pixel unit) // ROUND DOWN
horizontalGrid = (fPlayerY/TILE_SIZE)*TILE_SIZE + TILE_SIZE;
// compute distance to the next horizontal wall
distToNextHorizontalGrid = TILE_SIZE;
float xtemp = fITanTable[castArc]*(horizontalGrid-fPlayerY);
// we can get the vertical distance to that wall by // (horizontalGrid-GLplayerY) // we can get the horizontal distance to that wall by // 1/tan(arc)*verticalDistance // find the x interception to that wall
xIntersection = xtemp + fPlayerX;
} // else, the ray is facing up else {
horizontalGrid = (fPlayerY/TILE_SIZE)*TILE_SIZE;
distToNextHorizontalGrid = -TILE_SIZE;
horizontalGrid--;
} // LOOK FOR HORIZONTAL WALL if(castArc==ANGLE0 || castArc==ANGLE180) {
distToHorizontalGridBeingHit=9999999F;//Float.MAX_VALUE; } // else, move the ray until it hits a horizontal wall else {
distToNextXIntersection = fXStepTable[castArc];
while(true) {
xGridIndex = (int)(xIntersection/TILE_SIZE);
// in the picture, yGridIndex will be 1
yGridIndex = (horizontalGrid/TILE_SIZE);
if((xGridIndex>=MAP_WIDTH) ||
(yGridIndex>=MAP_HEIGHT) ||
xGridIndex<0 || yGridIndex<0) {
distToHorizontalGridBeingHit = Float.MAX_VALUE;
break;
} elseif((fMap[yGridIndex*MAP_WIDTH+xGridIndex])!=O) {
distToHorizontalGridBeingHit = (xIntersection-fPlayerX)*fICosTable[castArc];
break;
} // else, the ray is not blocked, extend to the next block else {
xIntersection += distToNextXIntersection;
horizontalGrid += distToNextHorizontalGrid;
} } }
// FOLLOW X RAY if(castArc < ANGLE90 || castArc > ANGLE270) {
verticalGrid = TILE_SIZE + (fPlayerX/TILE_SIZE)*TILE_SIZE;
distToNextVerticalGrid = TILE_SIZE;
// DRAW THE WALL SLICE
float scaleFactor;
float dist;
int topOfWall; // used to compute the top and bottom of the sliver that int bottomOfWall; // will be the staring point of floor and ceiling // determine which ray strikes a closer wall. // if yray distance to the wall is closer, the yDistance will be shorter than // the xDistance if(distToHorizontalGridBeingHit < distToVerticalGridBeingHit) { // the next function call (drawRayOnMap()) is not a part of raycating rendering part, // it just draws the ray on the overhead map to illustrate the raycasting process
drawRayOnOverheadMap(xIntersection, horizontalGrid);
dist=distToHorizontalGridBeingHit;
fOffscreenGraphics.setColor(Color.gray);
} // else, we use xray instead (meaning the vertical wall is closer than // the horizontal wall) else { // the next function call (drawRayOnMap()) is not a part of raycating rendering part, // it just draws the ray on the overhead map to illustrate the raycasting process
drawRayOnOverheadMap(verticalGrid, yIntersection);
dist=distToVerticalGridBeingHit;
fOffscreenGraphics.setColor(Color.darkGray);
}
Posted: Tue Mar 13, 2007 1:03 am Post subject: Re: Review: Ready to Program
I know this is an old thread, but now that Windows Vista is out (2007, expected 2003) I find Ready to Program very slow on Vista. I don't know if it's my machine (with only 512MB Ram [min. for Vista] ) but when I press F1, it seems a random delay of 1 to 60 seconds before the program will attempt execute. It sits there at "Executing file" with the loading wheel spinning on the cursor. If I press F1 a billion times, sometimes it launches faster.
ericfourfour
Posted: Thu Mar 15, 2007 4:38 pm Post subject: Re: Review: Ready to Program
That happens all the time at school. It is just goes slow because there is a lot of information to load onto the memory (try pressing F1 in Visual Studio). Don't worry, it isn't your machine. The help menu is simply an organized list of all of the items in the javadoc. You will find the same information with a simple google search.
Prince Pwn
Posted: Fri Mar 23, 2007 3:15 pm Post subject: Re: Review: Ready to Program
EDIT: Closing RTP and re-opening it will allow the code to execute instantly. It seems after it's loaded into memory, after a few executes it gets slower and slower.
FileFantasy
Posted: Sat Jun 28, 2008 5:46 pm Post subject: RE:Review: Ready to Program
With Holtsoft releasing Turing codes, I hope there'll be RTP codes soon so that we can get some open source RTP going.
Tony
Posted: Sat Jun 28, 2008 6:03 pm Post subject: RE:Review: Ready to Program
I would think that RTP, being made up of a collection of HSA class files, is already "open sourced" (as in, you should be able to view the source). Or reverse compile the libraries.
Posted: Sat Jun 28, 2008 7:36 pm Post subject: RE:Review: Ready to Program
Depends on what you mean by codes... The only codes available for Turing are some of the basic library, such as Str and Window, much of which are external anyway. Comparably, you could reverse the HSA libraries to view their source...
The way you put it, though, makes it seem like you're referring to the code for the environment (ie. the Turing IDE, the RTP IDE), which I'm pretty sure will not become available.
Sponsor Sponsor
Aziz
Posted: Sat Jun 28, 2008 11:33 pm Post subject: RE:Review: Ready to Program
The only comments I have are on the old posts, but since they haven't been brought up I'll post 'em anyways.
1) You can configure RTP to use any compiler you want. There's a setting where you point it to the javac.exe file, IIRC.
2) 512M ram on vista may be "minimum specs", but it's definitely not the minimum specs for a runnable machine. You need 1GB for basic office and web tasks to run smoothly.
and
3) I doubt the IDE is open-source, as nothing else of Holfsoft's is, but it is possible there are .java files for the HSA console. If not, the .class files can be reverse compiled with a fair amount of work (as long as they aren't horribly obfuscated)
Tony
Posted: Sun Jun 29, 2008 12:16 am Post subject: RE:Review: Ready to Program
Though there's no point in open sourcing the RTP IDE, as there are much better open source IDEs available (Eclipse).
Posted: Sun Jun 29, 2008 8:17 am Post subject: RE:Review: Ready to Program
Or Netbeans, or JCreator, or Notepad++, or anything else that's a Java IDE/Editor short of plain old notepad (I think vim would be able to syntax highlight, no?)
I think there's a list of IDEs somewhere in the java forums.
rizzix
Posted: Sun Jun 29, 2008 11:48 am Post subject: RE:Review: Ready to Program
Posted: Wed Oct 29, 2008 11:53 am Post subject: Re: Review: Ready to Program
Can anyone suggest a better alternative to Ready To Program? I tried Netbeans, seems user friendly, but commands such as 'import java.text.Decimal Format' and such results in me being told to remove the unused import command. I cannot format the resultant output to a certain decimal, which is required for my schoolwork.
Aziz
Posted: Wed Oct 29, 2008 12:43 pm Post subject: RE:Review: Ready to Program
You're simply being warned about that, because the import hasn't been used (yet). Warnings can be ignored, but they're helpful to follow (sensibly).
I'd also recommend Eclipse. Once you get used to it, you'll never want to use it for anything else. I use it for Java, PHP, C++, Python, and Java ME.
I also really used to like JCreator, so much that I bought a Pro version, but it's only worthwhile if you get the Pro and it's only Windows (as well as being Java-only).
HellblazerX
Posted: Wed Oct 29, 2008 12:46 pm Post subject: Re: Review: Ready to Program